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^ ABSTRACT 

Methods  for  detecting  logical  errors  in  computer  hardware  designs  using  symbolic 
manipulation  instead  of  digital  simulation  are  discussed.  A non-procedural  register  transfer 
language  is  proposed  that  is  suitable  for  describing  how  a digital  circuit  should  perform.  This 
language  can  also  be  used  to  describe  each  of  the  components  used  in  the  design. 
Transformations  are  presented  which  should  enable  the  designer  to  either  prove  or  disprove  that 
the  set  of  interconnected  componenu  correctly  satisfy  the  specifications  for  the  overall  system. 

The  problem  of  detecting  timing  anomalies  such  as  races,  hazards,  and  oscillations  is 
addressed.  Also  explored  are  some  interesting  relationships  between  the  problems  of  hardware 
verification  and  program  verification.  Finally,  the  resuitt  of  using  an  existing  proof  checking 
program  on  some  digital  circuits  are  presented.  Although  the  theorem  proving  approach  is  not 
very  efficient  for  simple  circuits,  it  becomes  increasingly  attractive  as  circuiU  become  more 
complex.  This  is  because  the  theorem  proving  approach  can  use  complicated  component 
specifications  without  reducing  them  to  the  gate  level. 

X 

Thii  thesis  was  submitted  to  the  Department  of  Computer  Science  and  the  Committee  on  Graduate 
Studies  of  Stanford  University  in  partial  fulfillment  of  the  recrements  for  the  degree  of  Doctor  of 
Philosophy. 

This  research  was  supported  by  the  Advanced  Research  Prefects  Agency  of  the  Department  of 
Defense  under  ARP  A Order  No.  2494,  Contract  MDA90S-?6~C-0206.  The  views  and  conclusions 
contained  in  t/Us  document  are  those  of  the  author(s)  and  should  not  be  interpreted  as  necessarily 
representing  the  official  policies,  either  expressed  or  implied,  of  Stanford  UrUverslty  or  any  agency 
of  the  U.  S.  Government. 


PREFACE 


This  thesis  represents  a first  attempt  at  developing  methods  for  proving  the 
correctness  of  computer  hardware  designs.  After  several  years  of  experience 
working  with  simulators  I realized  that  some  sort  of  symbolic  manipulation  program 
would  be  useful  In  detecting  errors  in  hardware  designs.  Initially  I decided  to 
pursue  hardware  verification  along  program  verification  lines,  but  the  Inherent 
lack  of  sequential  statement  execution  In  hardware  made  this  approach 
untenable.  There  Is  a point  at  which  program  verification  techniques  do  apply,  but 
not  until  a hardware  device  Is  a sequential  machine  with  a well  understood 
mechanism  for  determining  the  next  instruction.  To  verify  circuits  at  the  gate  and 
flip-flop  level  requires  some  very  different  tools. 

One  of  my  major  desires  was  to  do  all  of  this  in  a context  that  engineers 
would  understand  and  be  willing  to  use.  A very  simple  non-procedural  register 
transfer  language  Is  presented  that  can  be  learned  In  a few  minutes.  I believe 
that  it  includes  the  minimum  amount  of  control  Information  needed  to  prove  things 
about  how  a device  will  perform  in  conjunction  with  other  devices.  Naturally,  the 
specific  syntax  is  a function  of  the  keyboard  I am  using  and  many  equivalent 
languages  are  possible. 

Transformations  that  can  be  applied  to  statements  In  this  language  Include  the 
basic  boolean  operations,  definitions  of  arithmetic  functions,  and  some  special 
identities  that  enable  us  to  determine  the  effects  of  signal  transitions  as  they 
travel  thru  a circuit.  The  list  of  transformations  is  probably  far  from  complete  and 
will  have  to  be  expanded  as  special  hardware  problems  are  encountered.  An 
important  objective  Is  to  define  the  language  and  transformations  In  such  a way 
that  they  can  be  modelled  by  existing  proof  checking  programs.  A major  reason 
for  developing  hardware  verifiers  is  that  they  provide  a way  to  prove  the 
correctness  of  complex  devices  for  which  exhaustive  simulation  would  be 
impractical. 

I wish  to  thank  Lynn  Quam,  who  first  suggested  the  Idea  of  a hardware  verifier 
(in  the  context  of  a block  structured  design  automation  system)  as  a thesis 
project.  Richard  Weyhrauch  helped  me  with  using  his  FOL  (First-order  Logic) 
proof  checker  on  hardware  problems.  Finally,  director  John  McCarthy  and  the 
faculty,  students,  secretaries,  and  bureaucrats  have  all  made  working  at  the 
Stanford  Artificial  Intelligence  Lab  an  exciting  experience. 
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1.  INTRODUCTION 


This  thesis  discusses  a method  for  detecting  errors  In  digital  hardware 
designs.  A system,  or  module,  is  specified  using  a non-procedural  register 
transfer  language.  The  components  that  will  be  used  to  build  the  device  are  also 
specified  In  this  language.  A symbolic  manipulation  technique  can  then  be  used  to 
determine  If  the  interconnected  components  correctly  satisfy  the  specifications 
for  the  overall  system.  Essentially,  the  process  of  hardware  verification  Is  based 
on  boolean  reductions  and  some  methods  for  analyzing  the  consequences  of 
signal  transitions.  The  symbolic  manipulation  approach  should  be  able  to  detect 
timing  anomalies,  such  as  races  and  hazards,  in  addition  to  logical  Inconsistencies. 

The  desirability  of  using  proofs  of  correctness  to  detect  errors  in  hardware 
designs  has  been  discussed  previously  [1,4],  but  everyone  has  a different  Idea 
about  what  level  of  description  should  be  used.  Some  authors  think  In  terms  of  a 
finite  state  automaton  that  can  accept  or  reject  an  Input  sequence  depending  on 
the  algorithm  it  represents.  Still  others  are  Interested  In  determining  If  a given 
algorithm  correctly  implements  a complex  mathematical  function.  In  this  paper  a 
proof  of  correctness  will  based  on  showing  that,  for  any  single  Input  change, 
equivalent  state  changes  will  take  place  in  both  logic  descriptions.  In  other 
words,  if  both  models  of  the  logic  are  in  equivalent  states  and  the  same  Input 
variable  is  changed  on  each  of  them,  then  they  will  change  to  new  states  that 
are  also  equivalent. 

Hardware  verification,  as  presented  here.  Is  entirely  oriented  to  the  register 
transfer  level  of  system  description.  Problems  such  as  validation  of  physical 
layout  or  design  rule  checking  are  not  addressed.  The  circuit  level,  involving 
semiconductor  physics  and  critical  time  constants,  is  also  not  discussed. 
Nevertheless,  the  register  transfer  level  does  cover  a large  spectrum  of 
computer  design  activities.  It  can  be  used  to  determine  If  the  specifications  of 
an  Integrated  circuit  are  fulfilled  by  the  gates  within  the  chip,  or  if  a set  of  chips 
satisfy  the  definition  of  a complete  backplane.  These  techniques  can  also  be 
used  to  see  If  Interconnected  cards  or  backplanes  correctly  satisfy  the 
requirements  for  whole  computers. 

The  most  important  idea  behind  hardware  verification  Is  the  concept  of 
breaking  down  the  specifications  as  little  as  possible.  If  a designer  specifies  the 
operation  of  binary  addition  In  the  system  description  and  provides  an  adder  chip 
in  the  actual  circuit,  then  it  will  only  be  necessary  to  show  that  the  correct  data 
and  control  signals  are  sent  to  this  chip.  In  this  case,  breaking  the  addition 
operation  down  to  the  gate  level  will  not  be  necessary.  This  Is  especially  useful 
with  LSI  components  such  as  microprocessors.  The  microprocessor  can  supply 
the  complex  operations  and  the  verifier  will  only  have  to  show  that  the  support 
circuitry  sends  It  the,  correct  control  Information. 
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1.1  Basic  assumptions 

A couple  of  assumptions  must  be  made  regarding  timing.  Any  circuit  can  be 
made  to  operate  erroneously  If  certain  external  inputs  are  changed 
simultaneously,  so  race  detection  will  not  Include  these  circumstances.  If  the 
circuit  Is  to  be  used  In  conjunction  with  other  circuits  It  will  be  possible  to  detect 
races  In  the  composite  device  by  verifying  the  overall  circuit.  Components  will 
not  have  specific  delays.  When  a possible  race  is  detected  a hardware  verifier 
might  be  able  to  indicate  which  component(s)  most  be  faster  than  which  other 
component(s)  to  insure  correct  operation.  The  verification  process  does  not  say 
anything  about  how  fast  a circuit  will  operate,  only  that  It  will  work  correctly  at 
some  (slow  enough)  speed  if  the  races  and  hazards  are  taken  care  of. 

There  Is  also  the  philosophical  question  of  what  to  do  about  unspecified 
operations.  The  actual  circuit  will  almost  always  Include  other  operations  and 
state  variables  In  addition  to  those  specified  In  the  system  description.  If  a 
designer  uses  an  LSI  device  such  as  a microprocessor  to  perform  only  a few 
operations  there  will  be  a wealth  of  unspecified  operations.  A three  bit  counter 
can  be  implemented  by  using  a four  bit  counter  circuit  and  not  connecting  the  high 
order  bit.  At  the  same  time,  it  Is  easy  to  design  a circuit  in  which  the  unspecified 
operations  can  mean  disaster.  It  is  Important  to  be  able  to  differentiate  between 
additional  operations  that  are  acceptable  and  those  that  are  not,  since  a circuit 
can  satisfy  its  specifications  without  being  equivalent  to  them.  Some  solutions  to 
this  problem  are  discussed  in  the  section  on  feedback. 


1.2  Relationship  to  design  compilers 

At  present  there  are  a number  of  design  compilers  that  can  take  the 
specifications  for  a hardware  device  and  generate  the  necessary  circuitry.  The 
resulting  design  will  be  correct  and  have  a near  minimaH  number  of  gates  and  flip- 
flops  because  of  the  use  of  sophisticated  state  reduction  techniques.  Although 
fairly  successful,  design  compilers  have  several  shortcomings.  In  much  the  same 
way  that  good  hand  coding  of  software  can  beat  an  optimizing  compiler,  circuit 
designers  can  usually  find  novel  ways  to  use  components  that  a design  compiler 
would  miss.  With  current  LSI  components  It  Is  often  cheaper  to  throw  in  a 
complex  device  than  to  build  a circuit  using  the  minimal  number  of  gates  and  flip- 
flops.  A more  serious  problem  is  that  It  is  virtually  impossible  to  give  a design 
compiler  the  ability  to  use  more  than  a small  fraction  of  the  new  components 
rapidly  becoming  available.  Furthermore,  the  best  component  for  a given 
application  can  depend  on  such  varied  factors  as  price,  size,  and  shape  as  well 
as  the  usual  electrical  characteristics.  Under  these  circumstances.  It  would  seem 
more  reasonable  to  use  a program  that  lets  the  designer  use  whatever 
components  he  chooses  and  then  checks  for  design  errors. 

A major  advantage  of  a hardware  verifier  Is  that  It  can  provide  great 
flexibility  when  modifying  a circuit.  Suppose  that  a device  has  been  in  the  field 
for  a few  years  when  a new  component  Is  developed  that  can  replace  several 
used  in  the  original  design.  Using  hardware  verification  It  should  be  fairly  simple 
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to  determine  if  using  the  new  component  will  change  the  behavior  of  the  device  in 
any  way.  If  the  behavior  is  changed,  the  verification  system  can  indicate  what 
the  differences  are  so  they  can  be  dealt  with  appropriately. 

Incidentally,  one  approach  to  hardware  verification  has  been  to  submit  two 
specifications  for  the  same  device  to  a design  compiler  and  see  If  it  generates 
equivalent  circuits  [5].  It  is  unclear  how  this  would  be  used  when  one  description 
can  satisfy  the  other  without  being  equivalent  to  It. 


1 .3  Advantages  over  simulation 

The  most  popular  method  for  checking  hardware  designs  Is  digital  simulation. 
Earlier  attempts  at  comparing  high  level  and  low  level  descriptions  of  digital 
devices  based  on  simulation  are  discussed  In  [2,3].  Admittedly,  digital  simulation 
is  much  easier  to  implement  on  a computer  than  the  symbolic  manipulation 
techniques  presented  in  this  paper.  Simulation  methods  are  well  understood,  and 
are  very  useful  for  generation  of  fault  tests  that  can  be  used  to  speed  repairs 
after  a device  is  in  the  field.  On  the  other  hand,  simulation  cannot  determine  If  a 
design  is  correct  unless  it  is  exhaustive.  It  may  be  lucky  enough  to  find  some 
bugs,  but  others  may  go  undetected. 

The  greatest  disadvantage  of  simulation  is  that  certain  assumptions  must  be 
made  about  initialization,  delays,  and  the  possible  values  of  signals.  Unless  the 
logic  being  designed  has  a reset  signal  it  Is  Impossible  to  determine  the  Initial 
state  of  sequential  elements  at  power-up  time.  Some  simulators  assume  zero 
delay  components,  others  give  each  component  a unit  delay,  while  still  others 
give  each  component  type  a different  delay  value.  These  delay  values  may  have 
little  to  do  with  the  real  world  where  two  parts  of  the  same  type  can  have  very 
different  propagation  delays.  Simulators  are  generally  two  value  or  three  value. 
Two  value  simulators  use  only  zero  and  one,  while  three  value  simulators  Include 
an  undefined  state  to  be  used  during  initialization  and  signal  transitions.  Three 
value  simulators  can  detect  races,  even  where  they  don't  really  exist,  under 
certain  delay  assumptions. 

Hardware  verification  can  determine  correctness  of  a circuit  and  produce  a 
list  of  possible  races  and  hazards,  along  with  information  on  how  to  prevent  them. 
There  are  no  assumptions  about  circuit  Initialization  since  it  is  based  on  showing 
that  a circuit  satisfies  Its  specifications  regardless  of  Initial  state.  Hardware 
verification  will  also  generate  results  that  are  easier  to  Interpret.  It  can  show 
inconsistencies  in  the  context  of  boolean  expressions  Instead  of  the  pages  of 
ones  and  zeros  output  by  most  simulators.  Symbolic  manipulation  techniques  can 
often  be  much  faster  than  simulation  since  they  can  handle  arbitrarily  complex 
devices  without  always  breaking  them  down  to  the  gate  level. 
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2.  DESIGN  AUTOMATION  LANGUAGES 


An  incredible  number  of  hardware  design  languages  have  been  proposed,  many 
have  been  implemented,  and  several  have  become  popular  in  the  design 
community.  Entire  papers  have  been  devoted  to  the  philosophy  of  these 
languages  [7,9,16,27,36,38,46,49]  and  to  surveys  comparing  and  contrasting 
some  of  the  more  popular  ones  [8,26,33,60,61].  Design  automation  languages 
are  generally  classified  as  structural  or  behavioral,  although  some  attempt  to  be 
both.  Structural  languages  are  primarily  intended  to  provide  Information  such  as 
where  data  paths  go  and  where  control  lnformai..:fn  originates.  A good  example  of 
a purely  structural  language  Is  PMS  [11,12,47],  which  is  actually  Just  a 
formalized  notation  for  drawing  block  diagrams  of  computer  systems. 

Behavioral  languages,  on  the  other  hand,  attempt  to  describe  what  a system 
does  without  Implying  anything  about  the  hardware  structure.  These  languages 
are  often  used  as  simulation  models  and  to  help  In  software  production.  At  a 
somewhat  more  detailed  level  behavioral  languages  can  be  organized  to  provide 
some  inkling  of  how  the  system  itself  Is  organized,  but  they  could  just  as  easily 
imply  an  entirely  different  structure  and  still  emulate  the  hardware  correctly. 
Virtually  all  behavioral  languages  are  register  transfer  languages,  in  which  the 
basic  unit  of  Information  Is  a vector  of  binary  digits.  Since  they  were  first 
proposed  by  Reed  [42]  in  the  1960's  register  transfer  languages  have 
developed  into  procedural  and  non-procedural  types.  Several  of  the  procedural 
languages  have  complex  control  structures  that  permit  them  to  operate  In  a non- 
procedural manner. 


2.1  Procedural  register  transfer  languages 

Most  procedural  register  transfer  languages  are  programming  languages 
modified  to  handle  register  operations.  Instructions  are  executed  sequentially, 
but  In  some  languages  special  constructs  are  provided  to  permit  parallel 
execution  of  blocks.  Several  procedural  hardware  languages  are  based  on  APL 
[13,26,28,30,31,32],  whose  advocates  are  quick  to  point  out  the  tremendous 
power  of  the  vector  and  matrix  operations  already  in  the  language.  Although  very 
compact,  hardware  descriptions  In  APL-like  languages  are  among  the  most  difficult 
to  read.  Another  large  group  of  procedural  hardware  languages  are  based  on 
Algol  [9,11,12,22,29,35,46].  The  block  structure  of  Algol  can  often  be  used  to 
help  describe  the  system  structure. 

Still  other  procedural  languages  are  based  on  state  machines  [14,16,23,24]. 
In  state  machine  languages  the  logic  is  partitioned  Into  blocks  whose  execution  Is 
controlled  by  state  registers.  Special  Instructions  are  provided  to  allow  the  state 
registers  to  be  altered.  Finally,  there  are  some  languages  [34,39,44]  that  divide 
the  logic  Into  data  manipulation  blocks  and  a control  microprogram.  These  are 
essentially  the  same  as  the  state  machine  languages  except  that  In  the  latter 
the  control  microprogram  is  embedded  In  the  data  manipulation  blocks. 
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The  major  advantage  of  procedural  register  transfer  languages  Is  that 
algorithms  are  easy  to  read  and  understand.  Many  of  the  procedural  languages 
provide  subroutine  and  macro  facilities.  Since  there  Is  a definite  order  for 
executing  statements,  GOTO  statements  are  acceptable.  Procedural  hardware 
languages  are  excellent  for  systems  level  simulation  and  are  frequently  used 
when  producing  software  for  new  computers. 

Unfortunately,  the  details  of  how  the  control  and  timing  circuits  operate  are 
not  revealed  to  the  user.  Since  statements  are  executed  more  or  less 
sequentially,  it  Is  Implied  that  there  Is  some  control  logic  making  sure  things 
happen  at  the  correct  time.  In  many  procedural  languages  specifying  parallel 
operations  and  whether  an  operation  Is  synchronous  or  asynchronous  is  very 
difficult.  For  these  reasons,  the  hardware  verification  process  described  in  this 
paper  will  be  based  on  a non- procedural  register  transfer  language. 


2.2  Non-procedural  register  transfer  languages 

The  most  popular  non-procedural  register  transfer  language  is  called  the 
Computer  Design  Language,  or  CDL  [17,18,19,20,21].  This  popularity  is  largely 
due  to  fact  that  CDL  translators  and  simulators  have  been  made  available  to  the 
university  community.  Below  is  a COL  description  of  a stored  program  computer. 
First  come  the  declarations  which  specify  the  names  of  all  of  the  registers, 
switches,  and  circuit  nodes. 


Register, 

PC(0-11), 

IR(0-15), 

ACC(0-15), 

ADR(O-ll), 

CYCLE(0-1), 

G, 

Sprogram  counter 

Sinstructlon  register 
Saccumulator 

Saddress  register 

Scontrol  register 

Srun/haU  flag 

Subregister, 

IR(OP)=IR(0-3), 

IR(MA)=R(4-i5), 

Sopcode  part  of  IR 

Saddress  part  of  IR 

Memory, 

N(AOR)=M(0-4e95,e-15), 

Smemory  and  address  register 

Decoder, 

C(0-3)=CYCLE, 

I(0-15)=IR(OP), 

Sdecode  control  register 
Sdecode  Instruction  opcode 

Terminal , 

STOP=C(0), 

FETCH=C(1), 

EX=C(2), 

L0=l(8), 

ST=I(1), 

CLA=I(2), 

ADD:I(3), 

SUB:I(4j, 

JNPeI(5), 

Shalt  state 

Sinstructlon  fetch 
Sinstructlon  execute 

Sload  accumulator 

Sstore  accumulator 

Sclear  accumulator 

Sadd  Instruction 

Ssubtract  Instruction 

SJump  command 
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Switch,  RUN(ON),  Srun  button 

HALT(ON),  Shalt  button 

Clock,  T(l-2),  Stwo-phase  clock 

Register  declarations  define  the  size  and  bit  ordering  (msb-lsb)  for  each 
register,  while  subregister  declarations  permit  a group  of  bits  to  be  given  a 
special  name.  The  memory  declaration  specifies  both  the  size  of  a memory  and 
which  register  will  be  used  as  the  address  register.  Decoders  are  used  to  create 
a vector  In  v/hich  only  one  bit  Is  true,  selected  by  the  value  of  a register.  In  the 
example  above,  C(0)  will  be  true  If  CYCLE=0,  C(1)  will  be  true  If  CYCLE*  1,  and  so 
on.  Switch  statements  provide  variables  that  can  be  controlled  internally  by  the 
hardware  and  externally  by  data  supplied  to  the  CDL  simulator.  Terminal 
statements  are  used  to  rename  terminals  and  describe  logic  networks.  The  clock 
statement  can  provide  multiple  clock  phases,  and  In  this  example  clock  phases 
T(1)  and  T(2)  will  be  repeated  continuously. 

There  are  also  CDL  declarations  that  permit  several  operations  to  be  grouped 
into  a block,  creating  a sort  of  subroutIne/macro  facility.  Some  of  the 
declarations,  such  Ss  subregisters  and  terminals,  are  not  absolutely  necessary. 
The  same  logic  could  be  described  by  using  subscripts  and  the  original  terminal 
names  In  the  logic  description.  However,  these  declarations  do  tend  to  make  the 
description  easier  to  understand.  Below  are  the  statements  describing  the  actual 
operations  of  a computer  using  the  clocks  and  registers  declared  previously. 


Comment,  run  and  halt  controls. 

/RUN(ON)/  G«-l, 

/HALT(CN)/  G*-0, 

/ST0P*T(2)/  IF  (G=l)  THEN  (CYCLE-1), 

/EX*T(2)/  IF  (G=0)  THEN  (CYCLE-0)  ELSE  (CYCLE-1), 

Comment,  Instruction  and  operand  addressing. 
/FETCH*T(1)/  ADR-PC, 

/FETCH*T(2)/  IR-M(AOR),  CYCLE-2,  PC-countup  PC, 
/EX*T(1)/  ADR-IR(MA), 

Comment,  Instruction  execution. 


/LD*EX*T(2)/ 

/ST*EX*T(2)/ 

/CLA*EX*T(2)/ 

/ADDi»EX*T(2)/ 

/SUB*EX*T(2)/ 

/JMP*EX*T(2)/ 


ACC-M(AOR), 
M(ADR)-ACC, 
ACC-0, 

A-A  add  M(ADR), 
A-A  sub  n(ADR), 
PC-IR(MA), 

End 


The  expression  enclosed  In  slashes  is  a conditional  expression  where  the  "•*' 
should  be  interpreted  as  a logical  AND.  Most  statements  contain  one  or  more 
terminals  and  a clock  phase.  If  all  of  the  terminals  are  true,  then  the  operation 
indicated  will  occur  at  the  specified  time.  Although  they  make  the  description 
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more  readable,  the  IF-THEN  and  IF-THEN-ELSE  statements  are  not  really  needed. 
The  same  effects  could  be  obtained  by  modifying  the  conditional  expressions  to 
include  the  Information  In  the  IF  clauses.  Arithmetic  and  logical  operations  are 
performed  by  predefined  functions  such  as  "shr"  (shift  right),  "countup"  and  the 
like. 

Although  the  specific  syntax  of  declarations  and  statements  may  vary, 
virtually  all  non-procedural  register  transfer  languages  share  the  concept  of 
permitting  a conditional  label  to  be  attached  to  each  statement.  Obviously  a non- 
procedural hardware  description  is  more  detailed  than  a procedural  one.  At  the 
same  time,  algorithms  become  far  less  readable.  Macro-like  features  can  be 
provided,  but  true  subroutines  cannot  because  going  to  a routine  and  returning 
are  sequential  events.  Parallelism  Is  not  a problem  since  any  number  of 
statements  can  be  executed  at  the  same  time.  CDL  Is  good  for  describing 
synchronous  logic  but  cannot  be  used  for  asynchronous  circuits. 

The  Asynchronous  Circuit  Design  Language,  or  ACDL  [10],  permits  transitions 
such  as  X-*0  or  X-*l  in  the  conditional  expressions.  This  means  that  events  can  be 
described  as  happening  on  the  negative  or  positive  edge  of  signal  transitions. 
ACDL  is  a state  machine  language  which  uses  these  transitions  to  change  states. 
For  the  purpose  of  hardware  verification  we  will  develop  a language  similar  to  COL 
that  also  allows  transition  Information  In  the  conditional  expressions. 
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3.  HARDWARE  VERIFICATION  LANGUAGE 


Since  the  purpose  of  this  paper  is  to  discuss  hardware  verification  techniques 
and  not  to  create  yet  another  elegant  design  language,  the  language  presented 
here  is  extremely  simple.  Such  luxuries  as  macros  and  complex  operators  are  not 
included  at  this  time.  As  with  most  register  transfer  languages,  the  actual  syntax 
is  largely  a function  of  the  keyboard  available  to  the  author.  A BNF  description  of 
this  language  will  be  found  In  Appendix  A. 


3.1  Basic  syntax 

To  begin  with,  there  are  no  declarations.  Hardware  verification  Involves 
checking  a higher  level  description  of  a device  against  a lower  level  description 
of  the  same  device,  in  a sense,  the  higher  level  description  can  be  thought  of  as 
providing  the  register  declarations  for  the  lower  level  description.  In  other 
computer  design  languages  register  declarations  are  used  to  allocate  storage 
space  for  simulation.  This  Is  not  necessary  here  because  we  are  not  going  to 
simulate  the  logic.  Subregisters  and  memories  can  be  indicated  by  using 
subscripts  in  the  actual  statements.  Clock  declarations  are  not  needed  since  any 
variable  can  be  used  as  a clock.  Every  statement  will  be  In  one  of  the  two  forms 
shown  below.  The  conditional  expression  Is  optional  and  will  not  be  needed  when 
describing  combinational  devices. 

variable  *■  expression; 

/conditions/  variable  expression; 


3.2  Variables  and  constants 


A variable  name  must  begin  with  a letter  and  can  contain  letters,  digits,  single 
quotes,  and  underscores.  The  name  can  be  any  length.  Variables  may  also  have 
one  or  two  subscripts  enclosed  In  square  brackets.  If  there  are  two  subscripts, 
they  are  separated  by  a comma.  The  first  subscript  is  a bit  number  and  can  be  a 
constant,  two  constants  separated  by  a colon,  or  an  expression.  The  second 
subscript  is  a memory  location  and  may  be  a constant  or  an  expression. 
Additionally,  variables  can  be  Joined  using  the  (concatenation)  operator. 
Some  examples  of  variables  are  shown  below. 


X123’ 

PROGRAM  COUNTER 
ACC[3] 

INDEX[e:15] 

REGl[BIT[e:3]] 

MEMOR Y[ e : 1 5 . PC[ 0 : 1 5 ]4BASE  RE6[ 8:15]] 
A[0]8iB[2:5] 
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[ For  the  time  being  constants  are  in  decimal.  Binary  constants  can  be  written  as 

j ones  and  zeroes  concatenated  together. 

I 

! 

3.3  Expressions  and  operators 

Expressions  can  consist  of  variables,  constants,  and  other  expressions  joined 
by  various  logical  and  arithmetic  operators.  The  result  of  an  expression  can  be 
^ one  bit  or  a vector  of  bits.  Below  is  a list  of  the  operators  in  order  of  their 

precedence.  Parentheses  can  be  used  to  alter  precedence,  and  operations  of 
equal  precedence  are  evaluated  from  left  to  right. 

, logical  complement 

[ t r transitions  (conditional  exp.  only) 

& concatenation 

I -f  - arithmetic  operations 

[ = ^ > < ^ S arithmetic  relations 

r A logical  and 

t V • • logical  or/exclusive  or 

Conditional  expressions  are  similar  to  other  expressions  except  that  they 
must  have  a one-bit  (true/false)  result.  This  means  that  conditional  expressions 
; can  have  the  above  operations  (except  concatenation)  performed  on  one-bit 

j operands,  and  may  include  arithmetic  relations  when  comparing  bit  vectors. 

The  transition  operators  are  "t"  (0-»l  transition)  and  (l-»8  transition). 
These  can  only  be  used  in  conditional  expressions,  and  must  only  be  applied  to 
one-bit  operands  or  subexpressions.  It  is  Important  to  avoid  constructs  such  as 
"-it"  and  "-it"  except  to  indicate  feedback  states  In  which  the  variable  does  not 
change.  Otherwise  it  would  Imply  that  state  changes  can  happen  as  a result  of  a 
transition  not  occuring.  A basic  assumption  In  hardware  vorification  is  that  events 
are  caused  by  other  events,  and  it  Is  unclear  how  we  should  handle  events  that 
are  the  result  of  non-events. 

/ntX/  A«-A;  (OK  - Indicates  feedback) 

/-itX/  A*-Y;  (not  acceptable) 


There  is  a special  meta  operator  designated  by  the  character.  It  Is  used 
in  conjunction  with  subscript  expressions  to  mean  all  values  not  equal  to  that 
expression.  In  other  words,  the  expression 

A[*B[0:7]] 

might  be  used  to  indicate  all  of  the  bits  in  register  A except  the  one  pointed  to 
by  the  value  in  register  B.  The  reasons  for  having  this  operator,  and  some  special 
rules  for  how  to  use  it,  are  discussed  in  the  section  of  feedback. 
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3.4  Language  examples 

Here  are  some  examples  of  statements  In  the  hardware  verification  language. 
Parentheses  are  added  for  clarity  In  some  places  where  the  precedence  of 
operations  would  have  done  the  correct  thing.  Note  that  some  logical  operations, 
such  as  shifts  and  rotates,  can  be  accomplished  thru  subscript  manipulation  and 
do  not  require  special  operators.  The  first  three  examples  represent  very  simple 
gates  and  flip-flops,  while  the  other  examples  are  what  might  be  found  in 
computer  descriptions  or  LSI  component  specifications. 

A«->(BaC);  (combinational) 

/CLK/  Q«-D;  (asynchronous) 

/-.CLK/  Q*-Q; 

/fCLK/  0«-(JaiQ)v(-iKaQ);  (synchronous) 

/-.tCLK/  O-O: 

/ ( OPCODE[  e : 5 }=e&l&e&e  )a t T2 / A[ e : l S ]<-A[  l ; l S ]&A[  e ] ; 

/(XAtPHASEl)v(YA*PHASE2)/  A[e:15)«iB[0:15]-B[15]&A[0:15]&B[0:14]; 

/FE TCHa ♦ ( T 1 aENABLE )/  INSTR[0 : 1 5 hHEMORYt 0 : 1 5 , PC[ 0 : 1 1 ] ] ; 

/ 1 P2v(  t P3aCL0CIC_ENAB ) / ACC[ BIT[ 0 ; 3 ]>-A[ 0 ]eOVERFLOV ; 
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In  order  to  show  that  a lower  level  description  of  a device  satisfies  some 
higher  ievel  specification,  we  must  develop  ways  to  manipulate  the  statements  in 
the  descriptions.  The  identities  in  this  section  are  those  that  the  author  has 
found  useful  In  solving  specific  verification  problems.  This  list  is  by  no  means 
complete,  and  additional  transformations  will  have  to  be  Invented  as  more  circuits 
are  analyzed. 

In  the  definitions  of  vector  operations  bit  0 is  the  most  significant  bit, 
although  the  opposite  bit  ordering  can  be  impiemented  just  as  easily.  Note  that  in 
most  of  these  definitions  X[i:J]  and  Y[i;J]  are  used  only  to  make  the  notation 
simpler.  These  definitions  are  valid  for  arbitrary  vectors  (exp18cexp2&...&expn) 
whether  they  are  part  of  the  same  register  or  not.  Generally  speaking,  letters 
near  the  end  of  the  alphabet  such  as  X,Y,  and  Z will  be  used  to  denote  arbitrary 
expressions,  including  variables.  Letters  at  the  beginning  of  the  alphabet,  namely 
A and  B,  will  indicate  variable  names  only. 

Arithmetic  operations  are  generally  defined  in  the  context  of  positive 
integers.  Other  arrangements,  such  as  2's  complement  or  signed  magnitude,  can 
be  developed  from  these  with  some  extra  logic  in  the  user's  circuit  descriptions. 
It  is  also  possible  to  implement  definitions  for  other  types  of  arithmetic  in  the 
verifier  itself. 


4.1  Boolean  reductions 

Switching  algebra  Identities  like  those  shown  below  can  be  found  in  most  logic 
design  texts.  The  list  beiow  is  neither  exhaustive  nor  Is  it  minimal.  A hardware 
verification  program  could  use  these  transformations  directly  In  a pattern 
matching  routine,  or  it  could  use  some  iterative  boolean  minimization  techniques 
based  on  only  a few  of  them.  The  first  few  axioms  define  the  basic  nature  of 
AND,  OR,  and  NOT. 

Tl.  -.0  s 1 
nl  ■ 8 

T2.  Xvl  i 1 
XaS  I e 

T3.  Xv0  I X 
XaI  I X 

T4.  XvX  s X 
XaX  s X 


T5.  -.(-.X)  i X 
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T6.  XV-.X  s 1 

XA-.X  E e 

The  next  few  transformations  involve  combinations  of  two  or  more  variables. 
They  can  be  derived  from  the  identities  above  by  substituting  ones  and  zeros  for 
the  variables. 

T7.  XvY  E YvX 
XaY  s YaX 

T8.  Xv(XaY)  e X 
Xa(XvY)  e X 

T9.  (Xv-,Y)aY  e XaY 
(Xa-.Y)vY  ■ XvY 

T10.  (XvY)vZ  I Xv(YvZ) 

(XaY)aZ  ■ Xa(YaZ) 

Til.  Xa(YvZ)  e (XaY)v(XaZ) 

Xv(YaZ)  e (XvY)a(XvZ) 

T12.  (XvY)a(-,XvZ)a(YvZ)  s (XvY)a(-,XvZ) 

(XaY)v(-.XaZ)v(YaZ)  e (XaY)v(-,XaZ) 

T13.  (XvY)a(-.XvZ)  e (XaZ)v(-.XaY) 

T14.  -.(XvY)  i -.Xa-iY 
t(XaY)  e ^Xv^Y 

The  last  Identity,  DeMorgan's  law,  is  valid  for  expressions  of  arbitrary  length. 
However,  the  two  variable  version  may  be  easier  to  implement  and  can  acheive 
the  same  result  by  being  applied  repeatedly.  It  may  also  be  convenient  to  define 
a series  of  transformations,  for  the  exclusive-or  function. 

XI.  (Xa-,Y)v(-,5(aY)  e X#Y 

X2.  X*e  E X 

X3.  X«1  E -.X 

X4.  X*X  s 0 

X5.  X*-.X  E 1 

X6.  XaY  E YaX 

X7.  (XaY)aZ  e Xa(YaZ) 
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4.2  Definitions  for  subscripts  and  concatenation 

Definitions  D1  thru  04  can  be  used  to  reduce  several  concatenated  variables 
into  a sin^ile  reciister  variable,  or  vice-versa.  The  first  two  are  used  to  change 
register  variables  with  only  one  or  two  subscripts  into  the  full  three  subscript 
format.  This  is  to  make  them  compatible  with  03  and  U4.  Another  approach  would 
be  to  develop  identities  like  D3  and  04  for  each  combination  of  one  or  two 
subscripts.  In  a hardware  verification  program  It  would  probably  be  easiest  to 
have  the  input  parser  convert  registers  into  the  three  subscript  format 
automatically. 

01 . AL  i ] * A[  i : i ] 

02.  Ati:J]  I A[i;j,9] 

03.  A[  i : j,  s )a<A[  j*l  :k,s]  • A[1:k,s] 
wliere  1^J<k 

04.  -.Af  i : j,  s]&-iA[  j+1  :k,s]  * iA[i:k,s] 
where  lsj<k 


Tlie  next  definition  points  out  that  concatenation  is  associative,  while  the 
following  three  sliow  that  penorming  a logical  operation  on  vectors  (of  equal 
length)  and  concatenating  the  result  is  equivalent  to  concatenating  the  vectors 
and  then  performing  the  logical  operation.  Keep  in  mind  that  these  definitions  are 
valid  for  arbitrary  vectors  which  do  not  have  to  be  part  of  the  same  register. 

05.  (X&Y)&Z  1 X&(Y&Z) 

06.  (X[i;j]AY[i:jJ)«.(X[j+l:k]AY[j+l:k])  i X[  i :k]AY[  1 :k] 
where  isj<k 

07.  (X[i:J]vY[1:j])&(X[j+l:k]vY[j*l:k])  ■ X[ 1 :k]vY[ 1 :k] 
where  1ij<k 

08.  (X[.i:j>Y[i:jJ)&(X[j+i:k]»Y[j+l:k])  i X[  t :k>Y[  1 :k] 
where  1^j<k 


Definitions  DO  and  DIO  (decoder)  show  how  to  expand  a variable  with  an 
expression  as  a subscript  when  it  is  used  as  the  destination  In  a register 
transfer.  The  definitions  are  neariy  identical,  except  that  09  is  used  when  the 
first  subscript  is  an  expression  and  010  Is  used  to  expand  the  second  subscript. 
If  a variable  has  expressions  for  both  subscripts  we  can  use  09  and  then  010  or 
vice-versa.  It  would  not  be  reasonable  to  expand  a statement  into  several 
thousand  using  these  definitions,  but  a theorem  prover  could  use  this  Information 
to  determine  the  status  of  specific  bits  in  a register  or  memory  without 
generating  statements  for  all  possible  values  of  n. 
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09.  m A[Y[i:j], s>Z; 

■ 

/XA(Y[1:j]=n)/  A[n,s>Z; 

Die.  m A[s,Y[1:J]>Z; 

I 

/XA(Y[i:J]=n)/  Ats,n]-Z; 

Similarly,  D1 1 and  D12  (multiplexor)  Indicate  how  to  expand  a variable  with  an 
expression  as  a subscript  when  that  variable  is  used  as  part  of  an  expression. 
This  Includes  conditional  expressions  as  well  as  register  transfer  expressions. 
As  before,  there  are  versions  for  the  first  subscript  and  the  second  subscript. 

on.  A[Y[i:j],s]  ■ 

(A[0,s]A(Y[i:J]=8))v(A[l,s]A(Y[1:JM))v...v 

(A[n,s]A(Y[1:J]=n)) 

when  A[Y[1:J],s]  is  used  In  an  expression 
DIZ.  Ats.Y[1:J]]  I 

(A[s,0]a(Y[1:J]=0))v(A[s,1]a(Y[1:J].1))v,..v 

(Ats,n]A(Y[1:J]=n)) 

when  A[s,Y[1:J]]  Is  used  In  an  expression 


4.3  Definitions  of  arithmetic  operators 

In  this  subsection  we  have  the  definitions  for  the  various  arithmetic 
operations  and  relations  permitted  In  the  language.  The  first  two  definitions  are 
for  the  carry  operation.  Definition  A1  puts  It  In  terms  of  AMDs  and  ORs,  while  A2 
provides  a way  to  combine  carries  from  vectors  to  determine  the  carry  function 
for  larger  vectors.  The  second  definition  will  probably  find  more  use  since  most 
adder  chips  provide  carry-ln  and  carry-out  pins  but  take  care  of  their  own 
Internal  carries. 

Al.  X[1]aY[1MX[1]vY[1])aCI  ■ carry(X[  1 ], Y[  1 ],CI) 

X[1]AY[1]v(X[1)yYt1])Acarry(XtUl:J],Y[Ul:J].CI)  ■ 
carry(X[1:J],Y[1:J],CI) 

A2.  carry(X[1:J],Y[1,J],carry(X[J+l:k].Y[J+l,k].CI)  s 
C8rry(X[1:k],Y[1:k],CI) 
where  1Sj<k 


Addition  is  a fairly  sophisticated  operation,  but  becomes  much  simpler  using 
the  carry  functions  defined  above.  It  can  be  specified  on  a bit  by  bit  level,  as  In 
A3,  or  as  a concatenation  of  adders  as  In  A4.  Once  again,  the  definition  which 
permits  us  to  concatenate  small  adder  chips  Into  big  adders  will  be  the  most 
useful  In  real  verification  problems.  The  carry-ln  (Cl)  bit  Is  Included  In  the 
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addition  definitions  to  facilitate  working  with  adder  chips  which  usually  include 
this  input. 

A3.  (X[  1 >Y[  1 ]#CARRY(Xt  1+1 : J],  Y[  1*1 : 

( X[ i+1 ]*Y[ 1 + 1 ]#CARRY{X[i+2:J],Y[ 1+2 :J]. Cl )&...& 
(X[J>Y[J>CI)  « X[f:j]+Y[1:j]+CI 

A4.  (X[i:j]+Y[f :j]+CARRY(X[J+l,k],Y[j+l,k].CI))& 

(X[  j+l:k]+Y[  j+l:k]+CI)  s X[  i :k>Y[  1 :k>CI 
where  i5j<k 

We  will  also  define  two  special  cases  of  addition,  subtraction  and  increment. 
Subtraction  can  be  implemented  In  either  ones-complement  or  twos-complement, 
and  the  carry-in  bit  defined  above  provides  an  easy  way  to  select  which. 
Although  increment  could  be  derived  from  the  addition  definition  as  needed,  we 
will  make  it  an  axiom.  This  can  make  some  verification  problems  much  shorter 
I since  increment  Is  a very  popular  function. 

A5.  X[  i : j]+-.Yt  » X[  i : j]-Y[  f : j]  (for  2’s  complement) 

X[  i : j]+-.Y(  1 : j]+0  ■ X[  i : j]-Y[  1 : j]  (for  I’s  complement) 

A6 . X[  i ]•(  X[  1+ 1 ]A . . . aX[  j ] )«<X[  1+1  ]•(  X[  1+2 ]A . . . aX[  J ] )& . . .&-,X[  J ] 

£ X[i:j]+1 

Next  come  the  arithmetic  relations.  Only  equal-to  and  greater-than  are 
defined  in  detail  because  the  others  can  be  defined  in  terms  of  these  two.  Single 
bit  comparisons  for  these  are  shown  In  A7  and  All,  while  bit  by  bit  comparisons 
are  provided  in  A8  and  A12.  The  definitions  in  A9  and  A13  show  how  individual 
comparator  chips  can  be  connected  to  form  larger  comparators. 

A7.  -X[1]*Y[1]  E X[1]=Y[1] 

A8.  (X[1)=Y[t])A(X[i+l]=Y[1+l])A...A(X[j>Y[J])  e X[  1 : J]=Y[  1 : J] 

A9.  (X[i:j]=Yti:j])A(X[J+l;k]»Y[j+l:k])  ■ X[ 1 ;k]=Yt 1 :k] 

where  1$J<k 

A10.  -(X[1:J]=Y[i:J])  e X[  1 :J]#Yt  1 : J] 

All.  X[1]a-.Y[1]  e X[1]>Y[1] 

A12 . ( X[  1 ]>Yt  1 ] )v(  ( X[  1 ]=  Y[  1 ] )aX[  1+1  )>Yt  1+1  ])v . . .v 

((X[i;j-l]=Y[1;j-l])AX[j]>Y[J])  ■ X[ 1 ; J]>Y[ 1 : J] 

i A13.  (X[1:J]>Y[1:J])v((X[1;J>Y[i:J])AX[J+l:k]>Y[J+l:k]) 

! ■ X[1;k]>Y[i:k] 

I where  1$J<k 
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A14.  Y[1:j]>X[1:J]  ■ Xt  1 : j]<Y[  1 :J] 

A15.  -.(X[1:j]>Y[l:j])  i Xt  1 : j]5Y[  1 :J] 

A16.  n(Y[1:j]>X[1:j])  ■ Xt 1 :J]^Y[1 :J] 

4.4  Miscellaneous  transformations 

There  are  several  transformations  that  permit  us  to  combine  statements  or 
expand  one  statement  Into  several  others.  We  will  consider  these  to  be 
"common-sense"  axioms.  The  first  axiom  changes  statements  that  do  not  have  a 
conditional  part  into  one  where  the  conditions  are  always  true.  This  is  so  they 
can  be  used  with  the  other  axioms  in  this  section.  It  could  be  invoked 
automatically  by  the  verifier's  input  parser.  Axiom  M2  lets  us  substitute  the 
expression  part  of  a combinational  statement  for  the  variable  when  that  variable 
appears  in. other  statements. 

Ml.  A-Y;  s /!/  A*-Y: 

M2.  /!/  A-Y;  o (A  • Y) 

Axiom  M3  allows  two  statements  affecting  the  same  variable  to  be  combined, 
provided  that  their  conditional  expressions  are  identical  except  for  one 
subexpression.  This  subexpression  must  be  complemented  in  one  statement  and 
uncomplemented  in  the  other.  The  next  axiom,  M4,  shows  how  any  variable  or 
expression  can  be  moved  out  of  the  register  transfer  part.  This  is  done  by 
creating  two  new  statements,  one  showing  what  would  happen  If  that  variable 
were  one  and  the  other  showing  what  would  happen  If  it  were  zero.  Axiom  M5 
allows  us  to  divide  statements  having  a logical  OR  in  the  conditional  part  into  two 
separate  statements,  or  to  combine  two  statements  with  the  same  register 
transfer  part.  Similarly,  M6  can  be  used  to  combine  statements  with  the  same 
conditional  expression  or  to  divide  a statement  Involving  vectors  Into  two  or  more 
statements. 

M3.  /Wa-X/  A-Y; 

/Wa  X/  A-Z; 

E 

/W/  A-(-.XaY)v(XaZ); 

M4.  /X/  A-...Y....; 

E 


/Xa  Y/  A*-;..1...: 
/va-y/  a*..  . .a. . . ! 
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M5.  /XvY/  A«-Z; 

I 

/X/  A-Z; 

/Y/  A-Z; 

H6.  /X/  A-Y;  (note:  A and  Y must  be  the  same 

/X/  B-Z;  length,  same  for  B and  Z) 

a 

/X/  A&B-Y&Z; 


The  next  two  transformations  state  that  If  a certain  variable  or  subexpression 
appears  in  both  the  conditional  expression  and  the  register  transfer  expression, 
then  it  may  be  possible  to  determine  what  its  value  will  be  when  that  event 
occurs.  Axiom  M9  is  similar  except  that  another  statement  effected  by  the  same 
conditions  can  control  the  value  of  a variable  in  the  register  transfer  expression. 
Since  there  is  the  possibility  of  a criticai  race  under  some  circumstances  these 
should  be  used  very  carefully. 

M7.  /X/  A-...Y,..; 

and  (XsY) 

* 

/X/  A-...1...; 

M8.  /X/  A-..-,Y...; 

and  (X^Y) 

■ 

/X/  A-...e.. 

• H9.  /X/  A-...B...; 

m B-Z; 
and  (XaY) 

/X/  A-...Z...: 


Axiom  M10  can  be  used  to  introduce  arbitrary  expressions  Into  the  conditional 
part  of  a statement.  This  axiom  will  normally  be  used  to  convert  statements  Into 
a form  that  can  be  used  elsewhere.  Finally,  axiom  Mil  can  be  used  when  a 
variable  appears  ANOed  with  an  expression  that  can  control  Its  value.  It  comes  In 
two  flavors,  complemented  and  uncomplemented. 

m A-Z; 

/XaY/  A-Z; 


Mie. 
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A major  problem  with  describing  components  In  the  language  used  here  Is  how 
to  separate  feedback  from  don't  cares.  Most  component  descriptions  will  not 
contain  every  possible  combination  of  conditional  expressions.  Those  undefined 
conditions  can  either  be  considered  don't  cares,  In  which  the  state  of  the  device 
may  change  in  some  random  manner,  or  feedback  states  In  which  the  component's 
state  variables  do  not  change.  Obviously  it  Is  necessary  to  differentiate 
between  the  two. 


5.1  Implicit  feedback 

This  subsection  represents  something  of  a digression  because,  after  exploring 
the  possibilities  of  making  feedback  implicit,  the  author  decided  to  use  explicit 
feedback  for  the  proofs  in  this  paper.  Nevertheless,  it  may  be  reasonable  to 
implement  some  of  these  ideas  depending  on  the  structure  of  the  proof  checker 
being  used. 

If  feedback  is  to  be  Implicit,  then  statements  must  be  added  to  a circuit 
description  to  specify  when  a variable  can  enter  a "don't  care"  state.  This  can 
become  very  messy  when  using  a component  having  several  undefined 
operations.  In  a microprocessor,  for  example,  statements  such  as 

/(OPCODE[0:7]=''100)AtTl/  ACC[0:7>  don’t  care; 

/(OPCODE[0:7]=''100)AtTl/  Xt0:7]-  don’t  care; 

/(OPCODE[0:7]="100)AtTl/  Y[0:7]-  don’t  care; 

/(OPCODE[0:7]="100)AtTl/  PC[0:15]-  don’t  care; 

will  have  to  be  added  for  each  undefined  opcode.  Some  of  thlsi  might  be 
circumvented  by  developing  meta  operators  to  cover  large  numbers  of  undefined 
operations. 

On  the  other  hand,  using  implicit  feedback  means  that  a component  will  not 
change  state  unless  specifically  changed  by  some  statement.  Statements  of  the 
form 


m A«-A; 

/-.fX/  A*-A; 

are  not  needed  In  component  descriptions.  This  is  especially  convenient  when 
defining  registers  and  memories.  If  one  is  writting  data  Into  a memory  It  will  not 
be  necessary  to  show  that  locations  other  than  the  one  being  addressed  remain 
unchanged. 
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Since  unspecified  conditions  imply  that  the  system  will  not  change  state, 
statements  with  explicit  feedback  can  be  discarded  from  a logic  description. 
Here  are  three  transformations  In  which  statements  are  completely  eliminated: 

/X/  A-A;  i null 

(1) 

/XaA/  A«-1;  I null 

(2) 

/Xa-iA/  A*-0;  s null 

(3) 

The  first  one  permits  us  to  remove  a statement  with  explicit  feedback  because 
the  language  assumes  that  the  variable  will  remain  the  same  unless  explicitly 
altered.  The  other  two  statement  types  can  be  removed  because  they  don't  do 
anything.  In  the  second  example  the  variable  must  already  be  one  In  order  for  it 
to  be  set  to  one.  The  third  example  is  similar  to  the  second  and  shows  a case 
where  a variable  must  be  zero  in  order  to  be  set  to  zero. 

We  can  also  derive  some  general 
changed  from  the  conditional  expression, 
identities: 

rules  for  removing  the  variable  being 
To  do  this  we  first  need  the  following 

/XaA/  A-0;  ■ /X/  A»-0; 

(4) 

/XA-.A/  A-1;  I /X/  A*-l; 

(5) 

The  left  side  of  (4)  says  that  if  the  expression  Is  true  and  the  variable  Is  true, 
then  the  variable  goes  to  zero.  If  the  variable  is  already  zero,  then  It  will  remain 
that  way.  Therefore,  whenever  the  expression  is  true,  the  variable  will  be  zero. 
Identity  (5)  uses  similar  reasoning.  Using  these  transformations  we  can  now 
derive  the  following  general  rules: 

/XaA/  A*-Y:  1 /Xa-Y/  A^0; 

(6) 

/Xa-^/  A-Y;  ■ /XaY/  A«-1; 

(7) 

The  derivation  for  theorem  (6)  is  shown  below,  and  theorem  (7)  can  be  derived  In 
exactly  the  same  way  with  certain  variables  complemented. 

/XaA/  A-Y; 

given 

/XaAaY/  A-1; 

/XaAa-.Y/  A-0; 

N4 

/XaAa-Y/  A*^0: 

other  statement  eliminated 
using  (2) 

/Xa-Y/  A-8; 

(4) 

r 
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It  is  apparent  that  implicit  feedback  can  provide  some  fairly  compact 
component  descriptions  and  that  transformations  (1-7)  make  It  easy  to  simplify 
some  statements.  Unfortunately,  when  proving  the  correctness  of  a circuit  It  may 
be  necessary  to  show  that  a given  variable  does  not  change  state  under  certain 
circumstances.  Using  Implicit  feedback  this  would  amount  to  checking  all  of  the 
statements  Involving  that  variable  to  make  sure  none  of  them  can  cause  a 
change.  With  many  proof  checkers,  Including  the  FOL  system  discussed  in  this 
paper.  It  is  much  easier  to  make  feedback  explicit  and  then  verify  statements 
like 

/X/  A-A; 


the  same  way  other  register  transfers  are  verified.  For  this  reason  we  will  use 
explicit  feedback  for  the  remainder  of  this  paper. 


6.2  Axioms  for  explicit  feedback 

By  using  explicit  feedback  the  problem  of  specifying  don't  care  conditions  Is 
immediately  eliminated.  Any  set  of  conditions  not  accounted  for  in  a component 
description  corresponds  to  a don't  care  state.  On  the  other  hand,  some 
component  descriptions  may  become  somewhat  longer  since  statements  must  be 
added  to  Indicate  conditions  under  which  the  state  of  a variable  does  not  change. 

The  only  major  problem  Is  In  specifying  registers  and  memories.  In  which  large 
numbers  of  variables  remain  Unchanged.  To  solve  this  we  have  the  meta  operator 
which  Is  used  to  Indicate  all  locations  other  than  the  addressed  location. 
Using  this,  a typical  random  access  memory  might  be  defined  as  follows: 

/WRITE/  MEMOR Y[ 0 ; 7 , AD0R[ 0:11] >DATA[ 0:7]; 

/-.WRITE/  MEMOR Y[ 0 : 7 , A0DR[ 0:11] ]-MEM0R Y[ 0:7, A0DR[ 0:11]]; 

MEMOR Y[ 0:7, » ADDR[ 0:11]  )-MEMORYt  0:7, • A00R[ 0:11]]; 

This  would  mean  that  the  unaddressed  locations  represent  feedback  conditions 
whether  the  memory  is  being  read  or  written.  To  completely  formalize  the  notion 
of  the  operator  we  need  a few  more  axioms.  Axioms  F1  and  F2  permit  all  of 
the  unaddressed  bits  to  be  set  to  the  same  expression,  while  F3  and  F4  have  the 
unaddressed  bits  remaining  at  their  current  value. 

FI.  /X/  A[*Y[1:j],s]-Z: 

I 

/XA(Y[1:J].«n)/  A[n, s>Z; 

F2.  /X/  A[s,*Y[f;J]]-Z; 

B 

/XA(Y[l:J]iin)/  Ats,n]-Z; 
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F3.  /X/  A[*Yt1:j].s>-At*y[i:J],s]; 

■ 

/XA(Y[1:J]^n)/  A[n,i]*-A[n,s]; 

F4.  /X/  A[s,*Y[1:J]>-At5,«Y[l!j]]; 

i 

/Xa( Y[  1 :J>n)/  A[s,n]*-A[s,n]; 

Admittedly  the  operator  is  a kluge  designed  to  solve  the  problem  of 
defining  memories  with  explicit  feedback.  It  would  be  very  undesirable  to 
actually  expand  a memory  into  several  thousand  statements  using  the  above 
axioms.  They  can,  however,  be  set  up  in  a proof  checker  so  that  the  user  can 
ask  if  a given  set  of  locations  change  or  remain  the  same  under  specific 
circumstances.  The  "•'*  operator  should  only  be  used  In  context  shown  above.  It 
is  unclear  what  we  would  do  with  expressions  containing  several  terms 
combined  with  logic  operators. 
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In  this  section  we  will  develop  some  Identities  that  permit  us  to  study  the 
effects  of  signal  transitions  as  they  travel  thru  a circuit.  The  concept  of  a 
transition  algebra  was  first  proposed  by  Talantsev  [68]  in  1968.  Since  then, 
these  constructs  have  been  applied  to  the  problem  of  designing  circuits  using 
edge  triggered  flip-flops  [63,64,67]. 


6.1  Basic  axioms 

Figure  6.1  illustrates  the  nature  of  the  transition  operators.  The  expression 
"fX"  refers  to  that  Incredibly  short  period  of  time  during  which  variable  X 
changes  from  0 to  1,  and  Is  best  thought  of  as  a pulse.  The  fact  that  constants 
do  not  undergo  transitions  is  illustrated  in  Cl.  Axiom  C2  tells  us  that  a signal 
cannot  be  changing  from  0 to  1 and  from  1 to  0 at  the  same  instant.  It  will 
simplify  things  a great  deal  if  we  assume  that  two  variables  cannot  change  at 
exactly  the  same  time.  This  assumption  Is  reflected  In  axioms  C3  and  C4.  If  a 
transition  is  thought  of  as  a pulse,  going  from  0 to  1 and  back  to  0,  then  it  Is 
possible  to  think  of  that  pulse  as  having  two  transitions  associated  with  It.  This 
permits  us  to  use  axiom  C6  to  reduce  multiple  transition  operators  to  just  one 
(the  Innermost). 


Cl. 

te  E e 

tl  1 0 

te  a B 
il  ■ 8 

C2. 

tXAiX 

s 0 

C3. 

tXAtV 

E 0 

tXAiV 

E 0 

♦ XAtY 

E 0 

IXaIY 

a 0 

C4. 

tXatY 

s tXvtY 

tX»*Y 

s tXv*Y 

iXatY 

E iXvtY 

»Xa*Y 

E iXv*Y 

C5. 

ttX  s 

tX 

t*X  E 

*X 

*tX  i 

tx 

tiX  1 

tX 
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6.2  Mathematical  basis  of  transition  algebra 

This  subsection  contains  the  derivations  that  permit  us  to  develop  transition 
functions  for  switching  circuits.  To  begin  with,  any  variable  in  a logic  function  can 
be  factored  out  by  using  Shannon's  expansion  theorem  (very  similar  to  M4).  The 
resulting  expression  uses  two  new  functions.  They  are  the  same  as  the  original 
function  except  that  the  factored  out  variable  Is  set  to  1 In  one  of  them  and  0 in 
the  other. 


f(xi,X2 Xn)  » x/^j  V x^f^0  (1) 

Is  f(X|,X2,...,x„)  with  x^=l 
Is  f(xi,X2 Xp)  with  x^sB 

Whenever  these  two  new  functions  can  have  complementary  values  (due  to  the 
values  of  other  variables),  a transition  in  the  factored  out  variable  will  cause  a 
transition  in  the  original  function.  The  direction  of  this  transition  depends  on 
which  of  the  new  functions  has  the  value  of  0,  which  has  the  value  1,  and  the 
direction  of  the  transition  in  the  variable.  The  possible  ways  of  obtaining  positive 
or  negative  transitions  are  shown  below. 


tf  = ftifie^x^  V ftif^0*x^  (2) 

if  s '' 

To  find  all  possible  transitions  for  a given  function  it  is  necessary  to  develop 
expressions  like  (2)  and  (3)  for  every  variable  In  the  original  function,  and  OR  the 
results.  In  the  equations  below,  the  Sigma  should  be  Interpreted  as  a logical  OR. 


n 

t ^ fnfl0»xi  V fiifi0*Xi  (4) 

1'=1 


n 


*f(xi,X2 Xp)  = ^ fiifi0»Xi  v (5) 

1 = 1 
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6.3  Transitions  thru  combinational  circuits 

Usin^i  (4)  and  (5)  above  we  could  derive  transition  functions  for  any 
combinational  circuit.  However,  all  we  really  need  are  the  transition  functions  for 
AND,  OR,  and  INVERT  since  other  circuits  can  be  defined  In  terms  of  these  three. 
The  transformations  for  AND  and  OR  could  be  stated  for  arbitrary  numbers  of 
variables,  but  the  same  result  will  be  obtained  thru  repeated  application  of  the 
two  variable  versions.  Remember  that  X and  Y can  be  any  expression. 

C6.  tnX  I tX 
4-.X  i tX 

C7.  t(XAY)  E (tXAY)v(XAtY) 

*(XaY)  s (*XaY)v(Xa*Y) 

C8.  t(XvY)  s (tXA-.Y)v(-.XAtY) 

MXvY)  i (*XA-.Y)v(-.XAiY) 

To  sliow  how  the  above  transformations  are  applied  to  more  complex  circuits 
we  have  two  examples.  The  circuit  diagrams  are  shown  in  Figure  6.2.  The 
example  in  Figure  6.2a  Is  an  exclusive-OR  function. 

t(X*Y)  = t((XA^Y)v(-.XAY))  = 

t(XA-.Y)A-.(-.XAY)  V -,(XA-,Y)At(-.XAY)  = 

(tXAnY  V XAiY)A(Xv-.Y)  V (iXAY  v -,XAtY)A(-,XvY)  « 

( fXA-.YAX)v(tXA-.Y)v(XA*Y)v(XA*YA-.Y)v 
(j)fArA-,x>v(iXAyM-’XA»y>v(-XAtyAY)  » 


( tXA-.Y)v(XA*Y)v(*XAY)v(-.XAtY) 


Notice  how  terms  having  the  same  identifier  as  a transition  variable  and  a non-  j 

tran.sition  variable,  such  as  "tXAYA-.X",  were  eliminated  by  using  T8. 

Unfortunately,  this  does  not  always  happen.  Watch  what  happens  when  we  | 

derive  the  transition  function  for  the  circuit  in  Figure  6.2b.  I 

I 

t(XAY  V -XaZ)  * I 

a 

t(XAY)A-.(-.XAZ)  V t(-.XAZ)A-,(XAY)  . I 

(tXAY  V XAtY)A(X  V ~,l)  V (iXAZ  V -.XAtZ)A(-.X  V •,Y)  » f 

. • ^ 

(♦XAYAX)v(tXAYA-.Z)v(XAtY)v(XAtYA-.Z)v  I 

! ( *XAZA-.X)v(*XAZA-.Y)v(-.XAtZ)v(-.XAtZA-.Y)  « 

(tXAXAY)v(tXAYA-.Z)v(XAtV)v(*XA-.XAZ)v(*XA-.YAZ)v(^XAtZ)  \ 
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Elements  such  as  "tXAX..."  indicate  the  possibility  of  a hazard.  It  can  be  shown 
(Appendix  C)  that  any  circuit  having  a hazard  will  have  this  sort  of  expression. 
The  reverse  is  not  true,  and  terms  of  this  type  are  still  present  when  the  hazards 
have  been  corrected  by  consensus  gates. 

Another  problem  of  this  sort  arises  when  trying  to  expand  a non-transition  thru 
a combinational  circuit.  The  resulting  terms  seem  to  Indicate  the  possibility  of  a 
hazard  in  a non-transition.  We  could  add  some  axioms  to  make  these  extraneous 
terms  vanish  but  it  would  no  longer  be  true  that  i(itX)  is  equivalent  to  tX. 

. -,t(XAY)  s -.(tXAY  V XAtY)  « (-.tXv-.Y)A(-»Xv-itY)  • 

( -,t  XA-.X  )v( -.tXA-.tY)v( -.XAnY)v(  ^tYA-.Y) 

[ I 6.4  Transitions  thru  sequential  circuits 

I The  last  transformation  in  this  group  demonstrates  how  to  obtain  a transition 

at  the  output  of  a sequential  component.  Axiom  C9  is  easily  explained  if  we  think 
I of  a latch  like  the  one  in  Figure  6.2c,  in  which  the  output  follows  the  input  as  long 

[ as  the  clock  is  true.  A transition  will  develop  on  the  output  of  the  latch  if  the 

I data  input  undergoes  a transition  while  the  clock  Input  is  held  true*  Another  way 

» to  get  a transition  is  for  the  clock  input  to  switch  to  true  while  4be  data  Inputs 

[ are  set  to  switch  the  latch  to  a new  state. 

C9.  /X/  A^Y; 

I D 

tA  E (XAtY)v(-AAYAtX) 
iA  E (XAiY)v(AA-.YAtX) 

i 

] This  becomes  even  simpler  if  we  want  a transition  on  the  output  of  an  edge 

triggered  component  like  the  flip-flop  in  Figure  6.2d.  In  this  case  the  Input 
: changing  while  the  clock  Is  true  does  not  apply,  so  we  need  only  consider  the 

I second  part  of  the  expression:  the  clock  going  true  when  the  Inputs  can  cause 

\ an  output  transition.  It  is  possible  to  handle  this  special  case  with  another 

[ transformation  similar  to  C9,  but  the  desired  results  can  be  obtained  using  the 

i identities  we  already  have.  This  particular  problem  was  the  major  reason  for 

[ including  C5  in  the  list  of  axioms. 


/tX/  A-Y; 

given 

j 

tA  = (tXAtY)v(ttXAYAiA)  « 

C9 

(tXAYA-,A) 

C3,C5 

i 

It  should  be  noted  that  thl$  Is  completely  consistent  with  the  idea  of 
expressing  combinational  circuits  as  statements  where  the  conditional  expression 
is  always  true. 

1 
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/!/  A-Y; 

given 

tA  = ( lAtV)v( f IaVaiA)  « 

C9 

tY 

Cl 

Other  problems  can  develop  if  the  transition  variable  being  expanded  is 
controlled  by  several  statements.  Generally  speaking,  the  correct  approach 
would  be  to  apply  the  transition  identities  to  each  of  the  statements  and  then  OR 
the  results  together.  This  will  work  unless  some  of  the  statements  are 
contradictory,  which  is  an  error  anyway.  Contradictory  statements  are  discussed 
in  the  section  on  error  conditions. 


6.6  Flip-flop  design  and  modelling 

The  transformations  presented  thus  far  are  not  sufficient  to  prove  the 
correctness  of  some  flip-flop  designs.  Simple  latches  such  as  those  In  Figure 
6.3a  and  Figure  6.3b  are  easily  verified.  On  the  other  hand,  edge  triggered 
devices  like  the  ones  in  Figure  6.3c  and  Figure  6.3d  cannot  be  verified  using 
these  methods  because  they  depend  on  hazards  being  carefully  adjusted  to  work 
correctly.  The  type-D  flip-flop  shown  in  Figure  6.3c,  for  example,  will  work 
correctly  only  If  the  delay  thru  the  first  latch  Is  longer  than  the  delay  thru  the 
inverter  connecting  the  two  clock  inputs.  The  manufacturer  will  bias  these  delays 
to  insure  correct  operation.  Additionally,  many  circuits  use  capacitance  Instead 
of  feedback  to  store  data.  For  these  reasons  we  will  not  attempt  to  verify  the 
correctness  of  flip-flop  designs.  If  a given  flip-flop  circuit  Is  known  to  work 
correctly  it  can  be  added  to  the  verification  scheme  as  an  axiom. 

It  is  important  that  components  be  modelled  carefully  if  the  proof  of 
correctness  is  to  be  valid.  Some  JK  master-slave  flip-flops,  like  the  one  drawn  in 
Figure  6.3d,  have  the  nasty  habit  of  ones-catching  [66,66].  This  means  that  a 
short  pulse  on  the  J or  K input  while  the  clock  Is  high  could  set  or  clear  the 
master  latch.  This  erroneous  data  would  then  be  transferred  to  the  slave  latch 
during  the  clock  transition.  Many  JK  flip-flops  are  designed  to  eliminate  ones- 
catching.  At  any  rate,  when  using  a JK  flip-flop  which  does  exhibit  this 
characteristic  it  should  be  modelled  as  two  sequential  devices.  By  specifying  the 
master  part  as  a latch  and  the  slave  part  as  an  edge  triggered  device  the  overall 
behavior  can  be  properly  described. 

/CaJa-O/  X-1; 

/CaKa  0/  X-0; 

/ «C/  Q*X: 

/-.*C/  (KO: 
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In  this  section  we  shali  explore  a variety  of  error  conditions,  such  as  races, 
hazards,  and  oscillations,  that  can  be  detected  In  the  hardware  descriptions.  It  is 
not  completely  clear  how  this  fits  in  with  the  idea  of  comparing  two  descriptions 
of  the  same  device  since  it  is  possible  to  include  error  conditions  in  higher  level 
system  specifications.  If  the  user's  system  description  Includes  a hazard,  for 
example,  then  the  actual  circuit  may  need  to  have  that  hazard  for  the  verifier  to 
prove  its  correctness.  Because  of  this  conflict  this  section  will  not  contain 
specific  rules  for  what  to  do  when  an  error  is  encountered.  It  Is  mainly  Intended 
to  show  under  what  conditions  an  error  can  exist,  and  why  a verifier  may  have 
trouble  proving  the  correctness  of  some  circuits. 


7.1  Race  and  hazard  jargon 

Now  we  come  to  the  question  of  timing.  To  show  correctness  It  Is  not  really 
necessary  to  know  specific  delay  times  or  to  make  any  assumptions  on  how  fast 
the  device  will  go.  Usually  a device  built  from  ECL  will  go  faster  than  one  built 
from  MOS,  but  both  can  be  logically  correct.  Nevertheless,  It  Is  possible  to 
develop  ways  to  detect  timing  anomalies  such  as  races  and  hazards  on  an 
algebraic  level  without  introducing  specific  delays. 

Static  and  dynamic  hazards  [61,62,65,66,68,69,70,73,74,76]  are  logical 
conditions  under  which  combinational  circuits  can  produce  spurious  transitions. 
The  actual  transitions,  created  by  a logic  hazard  and  specific  component  delays, 
are  called  hazard  pulses.  Some  authors  use  the  term  static- 1 hazard  to  refer  to 
a momentary  0 in  an  output  that  will  normally  be  1,  and  static-0  hazard  to  refer  to 
a momentary  1 result.  A typical  example  of  a static- 1 hazard  was  presented  In 
the  section  on  transition  algebra.  The  term  transient  hazard  Is  sometimes  used  to 
refer  to  a hazard  that  will  not  do  any  damage,  while  a steady  state  hazard  can 
affect  the  final  value  of  a state  variable.  A dynamic  hazard  Is  a momentary  0 and 
a momentary  1 occuring  on  an  output  as  it  changes  from  one  state  to  the  other. 
In  other  words,  a dynamic  hazard  causes  three  transitions  where  only  one  was 
expected. 

Some  papers  [69,60,63]  have  attacked  the  problem  of  detecting  hazard 
conditions  for  specific  multiple  Input  changes.  Such  hazards  are  often  refered  to 
as  M-hazards.  These  hazards  are  further  divided  Into  function  hazards  and  logic 
hazards.  A function  hazard  is  inherent  In  the  definition  of  the  logic,  while  a logic 
hazard  may  exist  In  a particular  Implementation  of  a circuit  which  could  otherwise 
be  constructed  without  hazards.  Although  the  problem  of  multiple  Input  hazards 
will  not  be  addressed  In  this  paper,  the  concepts  of  function  and  logic  hazards 
are  closely  related  to  the  problem  of  comparing  hazardous  system  specifications 
with  their  implementation. 
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An  essential  hazard  [61,65,67,69,71,74,76]  Is  a unique  set  of  conditions  In 
which  the  transition  of  an  Input  variable  causes  a transition  In  a state  variable, 
and  the  comparative  delays  In  these  transitions  can  determine  the  output  of  still 
another  state  variable.  By  Unger's  definition  [74]  a circuit  contains  an  essential 
hazard  if  the  result  after  one  input  transition  is  different  than  the  result  after 
three  input  transitions.  Essential  hazards  are  not  necessarily  bad,  and  are 
required  In  counting  circuits.  The  circuit  delays  must  be  adjusted  to  make  sure 
the  desired  effect  Is  achieved.  A similar  condition  la  a race  [64,67,60,74,76], 
except  that  a race  Involves  transitions  of  two  state  variables.  A critical  race  Is  a 
race  that  can  affect  the  final  state  of  the  circuit  (like  a steady  state  hazard). 

Race  and  hazard  terminology  will  be  used  somewhat  differently  in  this  paper 
as  a matter  of  convenience.  Since  static  and  dynamic  hazards  can  be  thought  of 
as  a "race"  between  a variable  and  Its  complement  (In  a combinational  circuit), 
and  an  essential  hazard  can  be  thought  of  as  a "race”  between  an  Input  variable 
and  a state  variable,  all  of  these  phenomena  will  often  be  refered  to  as  races. 
This  eliminates  the  problem  of  having  to  determine  which  variables  are  state 
variables  when  one  of  these  problems  Is  detected. 


7.2  Race  and  hazard  detection 

For  purposes  of  hardware  verification  we  are  oniy  Interested  in  races  that  can 
cause  a permanent  change  in  the  state  of  the  system  and  hazard  pulses  on  the 
outputs  of  a device  that  can  cause  a malfunction  when  the  circuit  is  used  In 
conjunction  with  other  equipment.  Output  hazards  tend  to  take  care  of 
themselves,  if  the  output  Is  from  state  variable  an  output  hazard  will  appear  as  a 
race  that  can  affect'  its  final  state.  If  the  output  Is  from  a combinational  circuit 
the  hazard  will  usually  show  up  In  the  boolean  expression  for  that  circuit. 

Figure  7.1a  is  a block  diagram  of  a race  condition.  A transition  in  variable  X 
passes  thru  circuits  A and  B,  which  might  be  combinational,  sequential,  or  Just 
wires.  If  the  final  state  of  circuit  C can  depend  on  whether  path  A Is  faster  than 
path  B,  then  we  have  race  condition.  After  using  the  transition  theorems  on  the 
circuit  the  statements  describing  circuit  C will  be  In  terms  of  the  input  variable  X 
and  the  state  variables  (if  any)  of  A and  B.  Races  will  then  be  apparent  In  one  of 
the  following  forms: 

1.  A static-8  hazard  In  a conditional  expression. 

/...stat1c-0  hazard.../  A*-X; 

2.  Any  static  or  dynamic  hazard  In  a transition 
variable. 

/,..t(stat1c  hazard).../  A»-X; 

/...i(stat1c  hazard).../  A«-X; 

/. . . t(dynam1c  hazard).../  A*-X; 

/. . . ^(dynamic  hazard).../  A*-X; 
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3.  X or  ANDed  with  tX  or  *X  In  the  conditional 
expression . 

/...XAtX.../  A-Y; 

/. . .Xa*X. . ./  A-Y; 

/.  .-.XAtX. . ./  A*-Y; 

/.  .-,Xa*X.  . ./  A*-Y; 

4.  X,  -.X,  tX  or  iX  In  the  conditional  expression 
with  X or  -iX  In  the  register  transfer  part. 

/...X.../  A»-...X...: 

/..-,X.../  A-...X...: 

/..tX.../  A-...X...; 

/..*X.../  A«-...X...: 

/...X.../  A-...-.X...; 

/..-•X.../  A«-...-,X...; 

/..tX.../  A«-...-.X...; 

/..iX.../  A-...iX...: 


Some  of  these  conditions  may  not  mean  disaster.  A dynamic  hazard  in  a 
conditional  expression  does  not  matter  if  we  are  merely  gating  some  data  into  a 
register.  On  the  other  hand,  if  something  else  can  happen  on  the  opposite 
transition,  or  the  register  transfer  part  involves  counting  or  shifting,  then  It  can 
be  very  important. 

Although  we  have  freely  Indicated  where  static  and  dynamic  hazards  can 
cause  problems,  we  have  not  said  anything  about  how  to  detect  them.  Static 
hazards  are  well  understood,  but  dynamic  hazards  are  extremely  difficult  to 
detect.  There  are,  however,  some  fairly  simple  conditions  under  which  static  and 
dynamic  hazards  cannot  exist  [65,66,68,69,70,76].  This  is  not  to  say  that  they 
necessarily  will  exist  if  these  conditions  are  not  met,  but  these  methods  are  easy 
to  Implement  and  will  probably  be  adequate  for  a verification  program.  A very 
simple  rule  would  be  to  say  that  hazards  cannot  exist  unless  a variable  appears 
both  complemented  and  uncomplemented  in  the  same  expression. 

It  should  be  noted  that  static  hazards  In  transition  expressions  will  become 
apparent  when  the  expression  is  expanded.  This  will  generate  two 
subexpressions  of  the  form  "tXAX"  and  ''tXAnX"  (or  "*XaX"  and  "tXAiX"). 
Adding  a consensus  gate  will  still  produce  two  subexpressions  of  this  form,  but 
they  will  be  In  terms  of  two  different  variables  such  as  "tYA-.Y"  and  "tZA-.Z".  It 
may  be  possible  to  develop  some  specific  rules  based  on  this,  but  for  the  time 
being  it  is  probably  easier  to  expand  the  minimal  transition  expression  and  then 
look  for  a consensus  gate  when  a possible  hazard  Is  detected.  Some  results  of 
expanding  transition  expressions  containing  static  hazards  are  shown  in  Appendix 
C. 


When  a race  Is  found  a verification  program  may  be  able  to  indicate  which 
portion  of  the  circuit  must  be  faster  to  Insure  correct  operation.  Another 
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approach  would  be  to  have  the  user  indicate  which  branch  Is  faster  and  let  the 
verifier  determine  If  the  circuit  Is  correct  under  that  assumption.  Eventually  It 
may  be  possible  to  include  statistical  information  on  component  delays  so  that 
hardware  verifier  can  determine  the  probability  of  a race  or  hazard. 


7.3  Oscillation 

Another  timitfy  anomaly,  oscillation,  can  also  be  detected  thru  careful 
examination  of  the  clrcuii  description.  Oscillation  can  occur  by  a variable  being 
repeatedly  complemented  or  by  a continuous  bit  rotation.  Figures  7.1b  and  7.1c 
illustrate  circuits  where  variable  Q be  complemented  as  long  as  X Is  true.  The 
only  difference  between  the  gate  circuit'  and  the  latch  circuit  is  that  the  latch  will 
remain  in  some  random  state  after  X goes  low.  Figure  7. Id  shows  a rotate  circuit 
that  will  keep  rotating  as  long  as  the  CLK  signal  is  true. 

Although  the  illustrations  show  very  simple  circuits,  an  oscillation  can  occur 
thru  arbitrary  amounts  of  combinational  and  sequential  logic.  The  only  requirement 
is  that  a variable  is  repeatedly  complemented,  or  that  two  or  more  state  variables 
are  exchanged  or  rotated  continuously.  In  the  latter  case  the  variables  can  be 
complemented  any  number  of  times  during  the  rotation.  Here  Is  an  example  of 
oscillation  involving  a few  statements: 

/X/  A*-B; 

/Y/  B-CaD; 

/Z/  C-^A; 


In  this  example,  oscillation  can  occur  only  if  X,Y,Z,  and  D are  all  true  at  the 
same  time.  A simple  algorithm  for  detecting  oscillation  in  a given  variable  would 
be  to  determine  the  conditions  under  which  each  of  the  variables  in  the  register 
transfer  expression  are  transferred  Into  that  variable.  Then  do  the  same  thing 
for  each  of  these  variables,  and  so  on  until  the  original  variable  or  Its  complement 
is  detected,  or  until  the  process  terminates.  An  oscillation  will  be  Indicated 
anytime  a variable  can  be  continuously  complemented,  or  when  a variable  Is 
rotated  (complemented  or  not)  thru  at  least  one  other  state  variable. 

This  algorithm  may  not  be  practical  in  that  It  can  grow  incredibly  large  trees 
and  consume  lots  of  computer  time,  but  it  is  hoped  that  most  branches  will  be 
pruned  very  quickly.  Anytime  the  process  reaches  a variable  that  is  controlled  by 
a transition  It  can  eliminate  that  variable  as  a possible  oscillation  path.  Branches 
can  also  be  eliminated  when  they  require  conditions  that  contradict  other 
conditions  farther  up  the  tree.  Below  are  two  variations  on  the  previous  example 
in  which  an  oscillation  will  not  occur.  In  the  first  we  have  replaced  Y with  tY,  and 
in  the  second  oscillation  is  prevented  because  X and  iX  would  both  have  to  be 
true  at  the  same  time. 
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/X/  A-B; 
/iY/  B*-CaD: 
m C--.A; 


/X/  A«-B: 
/-.X/  b*-caD: 
/Z/  c*-.A: 


7.4  Other  error  conditions 

A more  obvious  problem  for  a hardware  verifier  Is  that  of  contradictory 
statements.  By  comparing  statements  which  can  change  the  value  of  the  same 
variable  one  of  three  relationships  will  be  discovered.  The  conditional 
expressions  can  be  the  same,  they  can  be  different  but  not  exclusive,  or  they 
can  be  exclusive.  An  example  of  each  Is  shown  below. 


1. 

/X/ 

A-Y; 

/X/ 

A-Z; 

2. 

/W/ 

A-Y; 

/X/ 

A-Z; 

3. 

/VaX/  A-Y; 

/WaiX/  A*-Z; 

The  first  example  Is  undoubtedly  an  error  since  the  variable  must  be  set  to 
the  results  of  two  different  expressions  for  the  same  conditions.  The  second 
case  will  be  incorrect  only  if  the  circuit  using  this  device  can  cause  W and  X to 
the  true  at  the  same  time.  This  sort  of  problem  can  be  detected  by  verifying  the 
still  larger  circuit  In  which  this  device  Is  used.  If  this  larger  circuit  Includes  such 
things  as  an  operator's  console  then  there  Is  no  way  to  tell  if  the  operator  will 
push  the  wrong  two  buttons  at  the  same  time.  The  third  condition  Is  not  problem, 
and  can  be  reduced  to  a combinational  circuit  (using  M3)  If  V and  W are  identical. 

Many  types  of  Integrated  circuit  devices  permit  outputs  to  be  connected 
together  in  a wired-AND  or  a wired-OR  arrangement.  An  easy  way  to  avoid 
getting  into  problems  with  contradictory  statements  on  these  circuits  would  be  to 
include  the  appropriate  AND  or  OR  function  in  the  hardware  description  as  If  there 
were  additional  gates  In  thg  circuit. 
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This  section  on  microprogram  verification  has  been  included  for  several 
reasons.  To  begin  with,  there  are  some  Interesting  similarities  between  the 
problems  of  microcode  verification  and  hardware  verification.  A hardware 
verification  system  should  be  able  to  handle  descriptions  of  microprogrammed 
devices.  Also,  it  should  be  possible  to  interface  circuit  descriptions  In  a hardware 
verification  language  to  existing  microprogram  verifiers  to  determine  the 
correctness  of  microprograms  for  that  particular  device. 


8.1  Microprogram  vs.  program  verification 

Although  work  on  program  verification  has  been  going  on  for  about  ten  years, 
the  specific  problem  of  microprogram  verification  has  only  been  discussed  fairly 
recently.  Much  of  this  work  was  done  at  IBM  using  a hypothetical  computer 
called  the  S-machine  [77,78,81,82,83].  The  S-machine  is  a very  simple  stack 
machine  and  problems  Involving  the  control  structure  and  timing  constraints  were 
not  considered. 

The  distinction  between  microprogram  verification  and  program  verification  Is 
often  very  hazy.  One  major  difference  is  that  microprogram  verification  concerns 
a program  for  a precisely  defined  piece  of  hardware  Instead  of  using  generalized 
algebraic  language.  Details  like  word  length  and  register  structure  are  very 
important  In  microprogram  verification.  Additionally,  each  microprogram  instruction 
usually  specifies  several  internal  operations  that  may  happen  simultaneously. 

Microprograms  are  usually  loop  free  or  have  very  few  loops.  This  makes  the 
verification  problem  much  simpler  than  for  programs  In  general.  The  problem  of 
verifying  loopfree  microcode  is  discussed  in  [86].  One  other  observation  is  that 
the  desired  operation  of  a microprogram  Is  usually  described  as  an  algorithm 
rather  than  as  a result.  In  program  verification,  for  example,  a sorting  program  ‘ 
might  be  specified  by  saying  that  it  takes  an  array  of  numbers  and  returns  them 
in  numerical  order.  A microprogram  verification  problem,  on  the  other  hand,  will 
usually  involve  showing  that  a specific  algorithm  Is  followed  by  a detailed 
program.  For  this  reason  most  microprogram  verifiers  are  based  on  proving  that 
each  statement  In  the  algorithm  description  Is  satisfied  by  one  or  more 
microinstructions.  For  more  background  on  microprogram  verification  techniques 
see  [80,82]. 

Of  particular  Interest  is  the  STRUM  (STRUctured  Microprogramming  language) 
system  developed  at  UCLA[84].  This  system  uses  a very  popular  procedural 
register  transfer  language,  ISP  (Instruction  Set  Processor),  for  describing  the 
hardware  to  be  microprogrammed.  It  also  uses  generalized  program  verification 
techniques  rather  than  methods  specifically  tailored  to  microprogram  problems. 
This  means  that  loops  cause  fewer  problems  with  STRUM  than  they  do  with  some 
other  microprogram  verifiers. 
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8.2  Hardware  verification  for  wicrocoded  devices 

Since  the  hardware  verification  language  described  here  Is  non-procedural  It 
is  also  loopfree.  Microcoded  devices  can  be  specified  In  several  ways.  To 
define  a circuit  that  fetches  and  executes  instructions  pointed  to  by  a given 
register  (the  program  counter)  is  fairly  straightforward.  Thus  it  Is  simple  to  prove 
that  the  hardware  does  the  correct  thing  for  an  unspecified  microprogram. 

Verifying  that  a circuit  with  a specific  microprogram  is  correct  can  be  bandied 
in  one  of  two  ways.  Assuming  that  the  microprogram  is  stored  in  a read-oniy 
memory  it  is  possible  to  include  the  ROM  data  In  the  conditional  parts  of  the 
overall  design  specification.  This  would  result  in  a hardware  description  with 
statements  like: 

/(PC[0:15]=1000)AtT0/  A«-X; 

/(PCt0:15]=1001)AtT0/  B«-Y; 

/(PC[0:15]=1002)AtT0/  C-Z; 


Another  approach  would  be  to  describe  the  ROM  as  a combinational  circuit  in 
the  higher  level  specifications.  Although  very  cumbersome,  this  may  make  the 
hardware  description  more  readable  in  those  cases  where  the  designer  Is  actually 
using  the  ROM  in  place  of  several  other  combinational  circuits.  Facilities  could  be 
added  to  a hardware  verifier  to  permit  the  user  to  specify  the  contents  of  a ROM 
as  a bit  table,  combinational  equations,  or  both. 

Embedding  the  microprogram  In  the  hardware  description  Is  only  practical  for 
very  small  control  memories  since  the  entire  program  must  be  included  In  the 
higher  level  description.  For  larger  microprograms  It  would  be  much  more 
reasonable  to  use  other  microprogram  verification  techniques.  This  would  Involve 
converting  the  non-procedural  hardware  description  to  a procedural  one  by 
making  assertions  about  sequences  of  control  signals.  At  the  very  least  it  would 
be  necessary  to  indicate  that  certain  clock  inputs  change  continuously  In  a 
specific  sequence  and  that  the  hardware  has  a well  defined  mechanism  for 
determining  the  next  instruction,  such  as  a program  counter.  Adapting  the 
hardware  language  used  In  this  paper  to  program  verification  systems  would  be 
an  interesting  future  project. 
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In  this  section  we  will  discuss  how  the  FOL  (First  Order  Logic)  proof  checker 
[86,87,88,89]  can  be  used  to  prove  the  correctness  of  circuits.  FOL  Is  a manual 
proof  checker,  written  in  LISP,  which  permits  the  user  to  manipulate  assumptions 
(component  definitions)  using  a set  of  axioms  and  some  simple  commands. 


9.1  Syntax  modifications 

Since  the  FOL  proof  checker  is  designed  to  work  with  formal  logic  It  is 
necessary  to  convert  the  hardware  language  into  the  format  of  well-formed 
formulas  (WFFs).  Although  the  conditional  expression  can  be  related  to  the 
register  transfer  part  by  a logical  implies,  FOL  has  no  understanding  of 
dynamically  changing  variables.  In  other  words,  FOL  cannot  model  register 
transfers.  The  easiest  way  out  is  to  convert  statements  in  the  language  used  In 
this  paper  to  a function  of  three  arguments: 

/X/  A-Y;  becomes  F(X,A,Y) 

A*-Y;  becomes  F(1,A,Y) 


This  way  the  axioms  can  be  applied  to  these  functions,  and  the  results  can  be 
converted  back  Into  the  hardware  language  on  output  (at  the  time  of  this  writting 
the  Input  conversion  was  being  done  manually  and  the  output  conversion  had 
been  implemented  Inside  FOL). 

Another  minor  problem  involves  the  FOL  character  set.  Certain  logical  symbols 
including  a,v,-,,i,:,  and  o have  special  meanings  in  FOL.  The  logical  AND  operator, 
for  Instance,  Is  used  to  combine  WFFs  and  is  somewhat  different  than  the  bitwise 
AND  used  In  circuit  design.  To  make  this  more  clear  we  have  the  FOL 
representation  of  axiom  M6,  which  requires  that  the  first  statement  AND  the 
second  statement  be  true  for  the  result  to  be  valid. 

M6.  /X/  A-Y; 

/X/  B-Z; 

■ 

/X/  A&B-Y&Z; 

becomes 

AXIOM  M6:  Vx  a y b z.  (F(x,a,y)AF(x,b,z)iF(x,a&b,y&z)) ; ; 

The  other  logical  connectives  have  the  obvious  meanings  except  for  the  equals 
operator  (>).  Equals  works  Just  like  equivalence  (a)  except  that  It  can  be  used 
for  expressions  while  equivalence  can  only  be  used  with  WFFs.  Transformation 
T7  might  look  like: 
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AXIOM  T7:  Vx  y.  xny*ynx;; 

Because  the  standard  logical  connectives  are  already  in  use,  the  following 
special  symbols  will  be  used  as  boolean  connectives  when  we  want  a bitwise 
operator: 

complement 
n and 

u or 

••  equals 


The  FOL  declarations  and  axioms  that  will  be  used  In  the  examples  are  shown 
in  Appendix  D,  and  the  FOL  users  manual  [69]  can  explain  what  the  syntax 
means.  Three  special  functions  have  been  provided:  carry,  sub,  and  sue.  The 
carry  function  can  be  used  In  component  definitions  and  manipulated  by  axioms 
I such  as  A2  and  A4.  Sub  Is  a function  that  provides  a way  to  handle  subscripts. 

Only  the  first  subscript  is  provided  for  at  this  time  since  the  examples  do  not  use 
memories. 

Q[l]  becomes  sub(Q,l,l) 

Q[0:3]  becomes  sub(Q,0,3) 

The  successor  function  sue  is  attached  to  the  LISP  function  ADD1.  To  Illustrate 
its  use  we  have  the  FOL  version  of  definition  03: 

AXIOM  03:  Vx  f j k.  sab(x,1,j)8isub(x,suc(J),k)Bsub(x,1,k};; 


0.2  FOL  commands 

FOL  has  a weaith  of  very  powerful  commands,  but  only  a few  are  actually 
used  in  the  examples  that  follow.  How  to  define  AXIOMS  has  already  been  amply 
illustrated,  but  there  Is  a slight  problem  with  axiom  names.  When  an  axiom  has 
more  than  one  part,  like  most  of  the  T series  and  C series,  FOL  will  try  to  append 
the  numbers  1 , 2,  etc.  to  the  axiom  name  for  each  of  the  different  versions.  This 
means  that  If  we  try  to  define  both  parts  of  T1  using  only  this  name  we  will  get 
axioms  Til  and  T12.  This  can  cause  problems  if  there  are  other  axioms  with 
these  names.  A simple  solution  is  to  give  the  axioms  names  like  T1A  and  TIB,  as 
is  slK>wn  in  Appendix  0. 

Variable  names  are  declared  using  the  DECLARE  command  and  are  set  to  the 
type  INDCONST  (individual  constant)  for  signal  and  register  names.  The  ASSUME 
command  can  be  used  to  input  component  definitions.  Assumptions  are  really  just 
like  axioms  except  that  axiom  names  do  not  appear  In  the  Hst  of  dependencies 
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for  a given  proof  step.  Each  proof  step  has  a number  or  label  appearing  In 
parentheses  to  the  left.  The  dependencies  for  each  step  appear  In  parentheses 
on  the  right.  Assumptions  depend  on  themselves. 

The  aI  (AND  introduction)  command  can  combine  two  WPFs,  and  will  often  be 
used  to  put  two  statements  together  so  that  Mfi  can  be  used.  Similarly,  aE  (AND 
elimination)  can  separate  two  WFFs.  One  way  to  generate  a copy  of  an  axiom 
with  the  correct  variable  names  substituted  Is  with  the  VE  (FORALL  elimination) 
command.  Below  is  an  example  of  this  command  applied  to  axiom  D3  above. 

VE  03  Q 0 1 3;  . 

gives  the  result 

# sub(Q,0,l)&sub(Q,suc(l),3)=sub(Q.0,3) 


The  SIMPLIFY  command  will  cause  the  "suc(l)"  term  to  be  evaluated  and 
replaced  by  the  number  2.  To  substitute  the  right  side  of  the  above  equation  for 
the  left  side  In  another  statement  the  SUBSTR  command  is  used.  The  other 
substitution  command,  SUBST,  works  the  same  way  except  that  the  left  side  of 
the  expression  above  would  be  substituted  for  the  right  side.  SUBSTR  and  SUBST 
work  for  both  equals  and  equivalence. 

One  of  the  most  powerful  FOL  Instructions  is  the  TAUT  (tautology)  command.  It 
uses  a parallel  simulation  routine  to  determine  If  some  WFF  logically  follows  from 
the  axioms  and  assumptions.  The  WFF  can  include  other  WFFs  connected  by 
logical  operators.  For  our  purposes  the  TAUT  command  will  be  used  when  a VE 
produces  a step  containing  an  implies  connective. 

Having  to  use  a VE  and  a substitute  command  every  time  we  want  to  apply  an 
axiom  can  become  very  tiresome.  Fortunately,  FOL  has  a REWRITE  command  that 
will  apply  axioms  to  expressions  automatically.  Since  REWRITE  will  only  use 
axioms  in  a left  to  right  direction  It  will  sometimes  be  useful  to  have  reversed 
copies  of  some  axioms  (see  T10B  and  T10BR  In  Appendix  D).  REWRITE  will  use 
the  axioms  repeatedly  until  no  more  substitutions  can  be  made.  For  this  reason 
the  REWRITE  command  cannot  be  used  with  axioms  like  the  commutative  relation 
in  T7.  A REWRITE  using  this  axiom  will  result  in  an  infinite  loop. 

The  LOGICTREE  operator  can  be  used  to  link  several  axioms  together  so  they 
can  be  used  by  the  REWRiTE  command.  For  the  examples  in  the  following 
sections  we  wili  use  three  axiom  sets  linked  by  LOGICTREE  (see  Appendix  D). 
The  REDUCE  group  will  automatically  apply  axioms  T1  thru  T6,  and  to  help  with  the 
commutative  problem  these  axioms  have  been  defined  In  both  permutations.  The 
TRANS  group  contains  most  of  the  clock  transition  reductions.  A CONCATENATE 
group  has  been  Included  that  can  reduce  concatenated  terms  Just  as  If  simplified 
copies  of  D3  were  applied  repeatedly. 

The  only  time  FOL  Is  really  Inconvenient  Is  when  two  variables  that  can  be 
combined  In  some  way  are  separated  by  parentheses  or  need  to  be  commuted 
before  they  can  be  reduced.  Simplifying  exprosslona  like 
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(XnY)n-X 


can  take  several  steps.  It  Is  possible  to  work  out  the  transformation  once  and 
then  use  the  VI  (FORALL  introduction)  command  to  put  the  quantifiers  back  In.  By 
manipulating  the  axioms  that  would  be  used  to  simplify  the  expression  above  and 
then  using  VI  we  can  obtain  the  following: 

# Vx  y.  (xny)n~x=0 

This  result  can  then  be  used  with  the  REWRITE  command  whenever  an  expression 
of  this  sort  appears.  In  hardware  problemSi  where  there  is  a tremendous  amount 
of  redundancy  from  one  bit  to  the  next,  this  can  be  a terrific  timesaver. 

FOL  also  provides  a substantial  number  of  administrative  features  including 
some  fairly  involved  file  handling.  A backup  file  of  the  user's  typed  input  Is  kept 
in  case  the  system  crashes  or  a terrible  error  Is  made  that  cannot  be  remedied 
by  cancelling  proof  steps.  The  CANCEL  command  deletes  steps  only  from  the  end 
of  the  proof.  Other  commands  let  the  user  look  at  specific  steps  and  axioms 
already  in  the  proof.  To  reduce  typing  there  are  ways  to  refer  to  a specific 
expression  in  a given  step.  The  second  expression  in  step  127,  for  example, 
would  be  obtained  when  the  user  types  127:#2.  The  proofs  In  the  following 
sections  were  printed  out  by  the  FOL  print  routines,  which  often  substituted  the 
actual  expressions  where  the  author  only  typed  in  a couple  of  numbers. 
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As  our  first  example  of  a circuit  being  verified  by  POL  we  will  use  the 
synchronous  counter  shown  In  Figure  10.1.  To  make  the  proof  a little  simpler  we 
will  use  a JK  flip-flop  that  does  not  exhibit  ones-cstchlng.  Definitions  for  the 
components  used  in  these  examples  are  In  Appendix  E.  The  desired  goal  Is  to 
prove  the  following; 


/^CLEAR/  Q[0:3]-0! 
/CLEARniCLOCK/  Q[0:3>Ot» :3]+l : 
/CLEARfV-iCLOCK/  Q[0:3>O[0:3]: 


The  number  In  parentheses  6n  the  right  Indicates  the  proof  step  at  which  that 
result  was  achieved.  The  proof  is  incredibly  straightforward  because  the  circuit 
does  not  do  anything  complicated  with  the  clock  transitions.  Notice  how  steps 
20-23  are  used  to  create  a commuted  definition  for  exclusive-or.  After  working 
on  the  problem  for  a while  the  author  realized  that  the  exclusive-or  terms  were 
coming  out  reversed  relative  to  what  was  needed  to  fit  the  increment  axiom.  The 
problem  was  solved  by  cancelling  a few  steps  and  then  adding  steps  20-23. 
Only  the  final  result  is  shown  here. 


FIGURE  10.1  SYNCHRONOUS  COUNTER 


SYNCHRONOUS  COUNTER 

*****DECLARE  INDCONST  CLEAR. CLOCK. Q.X.Y; 

• ••••ASSUME  /~CLEAR/O[3>0;  ; 

1 /-vCLEAR/O[3]-0;  (1) 

•••••ASSUME  /CLEARn*CLOCK/0[3>-(lrKQ[3])u(<vlnQ[3]):  ; 

2 /CLEARniCLOCK/0[33*-(lfK0[3])u(~lnQ[3]);  (2) 

• ••••ASSUME  /CLEARrwiCLOCK/Q[3]*-0[3];  ; 

3 /CLEARrwtCL0CK/Q[3]-Q[3];  (3) 

• ••••ASSUME  /~CLEAR/O[2>0;  J 

I 

4 /-vCLEAR/O[2]-0:  (4) 

•••••ASSUME  /CLEARn*CLOCK/0[2]-(0[3]fw0[2])u(~0[3]n0[2]);  ; 

5 /CLEARn*CLOCK/Q[2]-(Q[3]n-Q[2])u(~Q[3]nQ[2]);  (5) 

• ••••ASSUME  /CLEARrwtCLOCK/Q[2>Q[2];  ; 

6 /CLEARn~*CLOCK/Q[2>Q[2];  (6) 

• ••••ASSUME  /~CLEAR/Q[1>«;  ; 

7 ACLEAR/O[1>0;  (7) 

• ••••ASSUME  /CLEARn*CLOCK/Q[l>-(XrwO[l])u(~XnO[l]);  ; 

8 /CLEARn*CLOCK/Q[l>-(XrwQ[l])u(^XnQ[l]);  (8) 

• ••••ASSUME  /CLEARn~iCLOCK/Q[l>Q[l];  ; 

9 /CLEARn~*CLOCK/0[l>0[l];  (9) 

• ••••ASSUME  /-CLEAR/0[8>-8;  ; 

10  /-vCLEAR/O[0>0:  (18) 

•••••ASSUME  /CLEARn*CLOCK/O[0HYfVvO[0])o(~YnQ[0]);  ; 

11  /CLEARn*CLOCK/Q[0>(YfwQ[0])u(vYnQ[8]);  (11) 

‘ f •••••ASSUME  /CLEARn^*CLOCK/Qt0>-O[0];  ; 

12  /CLEARfw*CLOCK/Q[0]-O[0];  (12) 

• ••••ASSUME  XH)[2]nQ[3];  ; 

, ♦ 

13  X^Q[2]nQ[3];  (13) 

•••••ASSUME  Y-(Qtl]nO[2])nO[3];  ; 

14  YM0[l]nQ[2))n0[3];  (14) 
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*****aI  (10  7); 

15  /-vCLEAR/Q[0]-0;  a /~CLEAR/0C  13-0;  (7  18) 

*****aI  (154): 

16  ( /~CLEAR/Q[0]-0;  A /-CLEAR/QC  l]-8;  )a  /~CLEAR/0[2]-8;  (4  7 18) 

*****aI  (16  1); 

17  ((  /-CLEAR/Q[0]-0;  a /~CLEAR/Q[  1 ]«-8;  )a  /<vCLEAR/QtZ]«-8;  )a  /-vCLEAR/X 

Q[3]-0;  (1  4 7 10) 

*****REWRITE  17  BY  { 16): 

18  /~CLEAR/((Q[0]«<Q[l])&Q[Z])&Q[3]-((8«‘8)&0)&0:  (14  7 10) 

*****REWRITE  18  BY  CONCATENATE: 

19  /~CLEAR/Q[0:3]«-((0&0)&0)&0;  (1  4 7 18) 

*****VE  XI  x,y: 

20  ((xn'>.y)u('vxny))  = (x«y) 
it*it**VE  X6  x,y: 

21  (x»y)=(y»x) 

*****SUBSTR  21  IN  20: 

22  ((yn~y)u(^xny))=(y0x) 

*****VI  22  X y: 

23  Vx  y.((xn~y)u(~xny))»(y»x) 

***ft*REWRirE  2 BY  REDUCE; 

24  /CLEARniCLOCK/0[3]— 0[3];  (2) 

*****REWRITE  5 BY  { 23); 

25  /CLEARr>*CLOCK/0[2]«-0[23*0[3];  (5) 

••***REWRITE  8 BY  { 23): 

26  /CLEARn4CLOCIC/Q[l]«-0[l]*X;  (8) 

*****VE  M2  X,0[2]nQ[3]; 

27  X-0[2]nQ[3];  3X«(Q[2]nO[3]) 

*****TAUT  X»(Q[2)nQ[3])  13,27; 

28  X=(0[2]n0[3])  (13) 

*****SUBSTR  28  IN  26; 
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j 

29  /CLEARn*CLOCK/0[l>0[lX0[2]n0[3]);  (8  13) 

*****REWRITE  11  BY  { 23); 

30  /CLEARniCLOCi(/O[0]*-Q[0>Y;  (11) 

*****VE  M2  Y,(0[l]n0[2])n0[3]: 

31  Y-(Q[l]nQ[2])nQ[3]:  3Y=( (Q[ nnQ[2 ])nQ[3]) 

*****TAUT  Y=((0[l]nQ[2])nQ[3])  14,31; 

32  Y=((Q[l]nQ[2])nQ[3])  (14) 

*****SUBSTR  32  IN  30; 

33  /CLEARniCLOCK/Q[0]-Q[0X(Q[l]nQ[2])nQ[3]);  (11  14) 

»****aI  ( 33  29 ) ; 

34  /CLEARniCLOCK/O[0>Q[0X(Q[l]nO[2])nQ[3));  a /CLEaRniCLOCK/OC  1 ]-QX 

[l]«(Q[2]nO[3]):  (8  11  13  14) 

*****aI  (34  25 ) ; 

35  ( /CLEARniCLOCK/O[0]»-Q[0X(Q[l]nQ[2])nQ[3]):  A /CLEARntCLOCK/Q[  1 ]-X 
0[lX0[2]nQ[3]);  )a  /CLEARniCLOC(C/Q[2]-Q[2>Q[3];  (5  8 11  13  14) 

*****aI  (35  24);  j 

36  ((  /CLEARniCLOCK/O[0>O[0X(O[l]nQ[2])nQt3]):  a /CLEARn*CLOCK/Q[  1 ]X  ! 

-0[  lX0f2]nQ[3]);  )a  /CLEARniCLOCK/0[2]-0[2]»0[3];  )a  /CLEARn*CLOCK/QX  i 

[3X0[3];  (2  5 8 11  13  14) 

*»***REWRITE  36  BY  { M6); 

37  /CLEARnKLOCK/((Q[0]&Q[l])&Q[2])«iQ[3X((Q[0X(Q[l]nQt2])nO[3]))&X 

(0[lX0[2]nQ[3])))&(0[2>Q[3]))&-Q[3];  (2  5 8 11  13  14) 

*****REWR1TE  37  BY  { A6); 

38  /CLEARn*CLOCK/((Q[0]&O[l])&Q[2])&Q[3]-(((Q[0]8.O[l])a.Q[2])&O[3])+l;X 
(25811  13  14) 

*****REWRITE  38  BY  CONCATENATE; 

39  /CLEARn*CLOCI<;/O[0:3]-Q[0:3]+l:  (2  5 8 11  13  14) 

*****aI  (12  9 ) ; 

40  /CLEARn~iCLOCK/O[0>O[0]:  a /CLEARn-iCLOCK/0[  1 ]-0[  1 ];  (9  12) 

*****aI  (40  6); 

41  ( /CLEARn-*CLOCK/Q[0]-O[0];  A /CLEARn-*CL0CK/0[ 1 ]»-0[ 1 ];  )a  /CLEARn^X 

iCLOCK/0[2]«-Q[2];  (6  9 12) 

**»**aI  (41  3); 
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42  ((  /CLEARnviCLOCK/O[ehQ[0];  A /CLEARfW*CLOCK/Q[  1 >Q[  1 ];  )a  /CLEARnX 

~*CIOCK/Q[2].-Q[2];  )a  /CLEARn~*CL0CK/0[3]-Q[3]:  (3  6 9 12) 

*****REWRnE  42  BY  { H6}; 

43  /Cl[ARn~iCLOCK/((Q[0]&O[l])M)[2])AO[3>((Q[0]AQ[l])&O[2])&O[3];  X 
(369  J2) 

*****REWRITE  43  BY  CONCATENATE; 

44  /CLEARn-viCLOCK/O[0:3>Qr0:3):  (3  6 9 12) 
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11.  RIPPLE  COUNTER 


The  next  verification  example  will  be  the  binary  ripple  counter  shown  in  Figure 
11.1.  The  desired  goal  is  the  same  as  for  the  last  example: 


/-vCLEAR/  Q[0:3>0: 

(17) 

/CLEARntCLOCK/  QtRtai-QCeiaj+l; 

(96) 

/CLEARn-viCLOCK/  Q[0:3>Q[0:3]; 

(lei) 

Although  the  circuit  is  simpler  than  the  synchronous  counter  in  terms  of  wires 
and  components,  the  proof  Is  much  more  complicated.  This  is  because  transition 
expressions  for  the  first  3 bits  must  be  determined  and  then  substituted  Into  the 
original  assumptions.  Many  of  the  steps  Involve  moving  variables  and 
parentheses  around  so  that  conditional  expressions  can  be  simplified.  Quantifiers 
are  used  to  a great  advantage  In  this  proof.  Steps  26-33,  for  example,  create  a 
special  version  of  transition  axiom  C9  that  can  be  used  for  edge-triggered  toggle 
devices  with  a clear  Input. 
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*****DECLARE  INDCONST  CLEAR, CLOCK, Q; 

*****ASSUME  /~CLEAR/Q[3>0;  ; 

1 /~CLEAR/Q[3]-0:  (1) 

«****ASSUME  /CLEARn*CLOCK/Q[3XlrvvQ[3])u(A'lnO[3]);  ; 

2 /CLEARntCLOCK/Q[3XlfVvQ[3])u(~lnO[3]);  (2) 
*****ASSUME  /CLEARn-*CLOCK/0[3]*K?t3];  ; 

3 /CLEARn-v*CLOCK/0[3>0[3];  (3) 

• ••••ASSUME  /-vCLEAR/0t2>e;  I 

4 /~CLEAR/Q[2>0;  (4) 

• ••••ASSUME  /CLEARn*0[3]/0[2>(l--w0[2])u(*lnQ[2]);  I 

5 /CLEARn*0[3]/0[2XlfwQ[2])u(*ln0[2]);  (5) 

• ••••ASSUME  /CLEARn-*0[3]/0[23*-0[2];  ; 

6 /CLEARn-iQ[3]/0[2>0[2];  (6) 

• ••••ASSUME  /~CLEAR/Q[l]»-0;  ; 

7 /-CLEAR/O[l]-0;  (7) 

•••••ASSUME  /CLEARn*Q[2]/Q[l>(ln~0[l])u(~inQ[l]);  ; 

8 /CLEARn*Q[2]/0[lXlfwQ[l])u(‘vlnQ[l]);  (8) 

• ••••ASSUME  /CLEARn~*0[2]/Q[l>Q[l];  : 

9 /CLEARn-iQ[2]/0tl]-0[l];  (9) 

• ••••ASSUME  /~CLEAR/Q[0>0;  ; 

10  /-CLEAR/Q[0>0;  (10)  . 

•••••ASSUME  /CLEARn*Q[l]/Ot0>(lfVvQ[0])u(<vlnQ[0]);  ; 

11  /CLEARn*Q[l]/Ot0]-(ln-Q[0])u(«.lnO[0]);  (11) 

• ••••ASSUME  /CLEARn-v*Q[l]/O[0]-O[0];  ; 

12  /CLEARn-viO[l]/Q[0>Qt0];  (12) 

•••••aI  (10  7); 

13  /-vCLEAR/O[0>0;  a /~CLEAR/Q[  1 >0 ; (7  10) 

•••••aI  (13  4); 

14  ( /~CLEAR/Qt0]-0;  A /~CLEAR/QC  1 >0;  )a  /~CLEAR/O[23«-0; 


(4  7 10) 
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*****aI  (14  1); 

15  ((  /~CLEAR/Q[0]«-0;  a /~CLEAR/Q[  1>0;  )a  /~CLEAR/Q[2>-0;  )a  /<vCLEAR/X 

Q(3>0;  (1  4 7 10) 

*****REWRITE  15  BY  { H6>; 

16  UCLEAR/((Q[$]aQ[l])&Q[2])W[3]-(($M)M)tS:  (14  7 10) 

*****REWRITE  16  BY  CONCATENATE; 

17  /^CLEAR/Q[0:3]«-((0&0)&0)ai0;  (1  4 7 10) 

*****VE  XI  x,y; 

18  ((xn~y)u(~xny))=(x»y) 

*****VE  X6  x,y; 

19  (x»y)=(y*x) 

*****SUBSTR  19  IN  18; 

20  ((xn~y)u(^xny))=(y*x) 

*****VI  20  X y; 

21  Vx  y.((xn'vy)u(<vxny))=(y»x) 

*****REWR1TE  2 BY  REDUCE; 

22  /CLEARn*CLOCK/Q[3>~Q[3];  (2) 

*****REWRITE  5 BY  REDUCE; 

23  /CLEARn*0[3]/Q[2]‘-~0[2];  (5) 

*****REWRITE  8 BY  REDUCE; 

24  /CLEARn*Q[2]/0[l>-0[l];  (8) 

*****REWRITE  11  BY  REDUCE; 

25  /CLEARniQ[l]7O[0>^[0]5  dU 

*****VE  T10BR  x,x,y; 

26  (xn(xny) )=( (xnx)ny) 

*****REWRITE  26  BY  REDUCE; 

27  (xn(xny))=(xny) 

*****VE  C9B  CLEARn*x,a,~a; 

28  /CLEARn*x/a«-^a;  3*as{((CLEARn*x)n*~a)u((afVv~a)nt(CLEARn*x))) 
*****REWRITE  28  BY  REDUCEuTRANSu(  T10B,27); 
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29  /CLEARn*x/a*-~a : 3*a*(an(CLEARn*x)) 

*****VE  T7B  a,CLEARn*x; 

30  (an(CLEARnix))=((CLEARn*x)na) 

*****SUBSTR  30  IN  29; 

.i  /CLEARn*x/a*-"^a : 3*a=( (CLEARn*x)na) 

*****REWRITE  31  BY  { TIBB}; 

32  /CLEARn4x/a«-~a:  3*a=(CLEARn( ixna) ) 

*****VI  32  X a; 

33  Vx  a.(  /CLEARnix/a^-'-a;  3*as(CLEARn( *xna) ) ) 

****»VE  33  CLOCK, 0[3]; 

34  /CLEARniCLOCK/0[3]— 0[3];  3*Q[3]=(CLEARn(iCL0CKnQt33)) 
*****TAUT  lO[3]=(CLEARn(*CLOCKnQ[3]))  22,34; 

35  tQ[3]s(CLEARn(*CL0CKnQ[3]))  (2) 

*****VE  33  0[3],0[2]; 

36  /CLEARniO[3]/Q[2]— Q[2];  =*Q[2]=(CLEARn(*Q[3]nQ[2])) 
*****TAUT  *Q[2]=(CLEARn(iO[3]nQ[2]))  23,36; 

37  t0[2]=(CLEARn(*0[3]n0[2]))  (5) 

*****SUBSTR  35  IN  37; 

38  *Q[2]=(CLEARn((CLEARn(*CLOCKnO[3]))nQ[2]))  (25) 
*»***REWRITE  38  BY  REDUCEu{  TIBB, 27); 

39  iO[2]=(CLEARn(iCLOCKn(0[3]nO[2])))  (25) 

*****VE  33  0[2].0[1]: 

40  /CLEARn*0[2]/0[l]*-0[l];  3*0[  1 ]=(CLEARn(  *Q[2]nO[  1 ]) ) 
*****TAUT  iO[l]=(CLEARn(iO[2]nQ[l]))  24,40; 

41  iQ[l]=(CLEARn(iO[2]nQ[l]))  (8) 

*****SUBSTR  39  IN  41; 

42  i0[l]=(CLEARn((CLEARn(iCL0CKn(0[3]n0[2])))n0[l]))  (2  5 8) 

*****REWRITE  42  BY  REDUCEu{  1108,27); 

43  i0[l>(CLEARn(*CLOCKn(0[3]n(0[2]n0[l]))))  (2  5 8) 

****ftSUBSTR  35  IN  23; 
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44  /CLEARn(CLEARn(*CLOCKnQ[3]))/Q[2>MJC2];  (2  5) 

*****REWRITE  44  BY  { 27); 

45  /CLEARn(*CLOCICnQ[3])/Qt2]«-«vO[2];  (2  5) 

*****SUBSTR  35  IN  6; 

46  /CLEARn~(CLEARn(*CLOCKnO(3]))/0[2>0(2];  (2  6) 

*****REWRITE  CLEARn-v(CLEARn(*CLOCI(nx))  BY  RE0UCEu{  T11A,T14B); 

47  ( CLE ARrvv ( CLEARn(  *CLOCKnx  )))=(( CLEARfwtCLOCIC  )o( CLEARrwx ) ) 
*(****REWRITE  /(CLEARfVviCLOCIC)o(CLEARfwx)/a»-a;  BY  ( M5>; 

48  /(CLEARn~iCLOCK)u(CLEARrwx)/a*-a;  ■(  /CLEARfw*CLOCIC/a»-a;  a /CLEARrwX 
x/a*-a;  ) 

*****SUBSTR  47  IN  48; 

49  /(CLEARfvviCLOCK)u(CLEARrwx)/a-a;  ■(  /CLEARn~*CLOCK/a«-a ; a /CLEARfwX 
x/a»-a;  ) 

*****VE  M10  CLEARrwx, *CLOCK, a, a; 

50  /CLEARn^x/a*-a;  d /( CLEARrwx )niCLOCIC/a*-a; 

****»REWRITE  50  BY  { T10B); 

51  /CLEARn-vx/a*-a;  = /CLEARn(~xn*CLOCK)/a*-a; 

*****VE  T7B  -vX,*CLOCK; 

52  (-vxn*CLOCK)  = (*CLOCKfwx) 

*****SUBSTR  52  IN  51; 

53  /CLEARn-vx/a-a;  a /CLEARn(  iCLOCKrwx)/a*-a; 

**»**TAUT  /(CLEARrwiCLOCK)u( CLEARrwx )/a*-a;  =(  /CLEARtw*CLOCK/a-a ; A /X 
CLEARn(iCLOCKn-vx)/a-a;  ) 49,53; 

54  /(CLEARn^*CLOCK)u(CLEARrwx)/a*-a;  =(  7CLEARrw*CL0CK/a*-a;  A /CLEARn(X 
*CLOCIi:n-x)/a*-a;  ) 

*****SUBST  47  IN  54; 

55  /CLEARrw(CLEARn(iCLOCKnx))/a*-a;  /CLEARfw*CLOCK/a*'a;  A /CLEARn(*X 
CLOCKn~x)/a»-a;  ) 

•**a*VI  55  X a; 

56  Vx  a.(  /CLEARrw(CLEARn(*CLOCKnx))/a«-a;  3(  /CLEAR(W*CLOCK/a«-a:  A /CLX 
EARr)(  tCLOCKrwx)/a«-a;  )) 


VE  56  Q[3],Q[2]; 
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57  /CLEARn-v(CLEARn(*CLOCKnO[3]))/Qt2]M)t2];  3(  /CLEARfw*CL0CIC/Q[2]«-Q[X 
2];  A /CLEARn(*CLOCICrwQ[3])/Q[2>Q[2];  ) 

*****TAUT  /CLEARrw»CLOCIC/QC2]M}[2]:  A /CLEARn(4CL0CKfwQt 3 ])/Qt 2 >-Q[ 2 ]X 
: 46,57; 

58  /CLEARfw*CLOCIC/Q[2>-Q[2];  A /CLEARn(*CLOCKfw0[3])/0[2]*HJ[2];  (2  * 

6) 

•****aE  58:#1; 

59  /CLEARrw*CLOC»:/Q[2>^2];  (2  6) 

*****aE  58:#2; 

60  /CLEARn(*CLOCICn-Qt3])/0[2>0(2];  (2  6) 

*****SUBSTR  39  IN  24; 

61  /CLEARn(CLEARn(iCL0CKn(Q[3]nQ[2])))/Q[l>-.Q[l];  (2  5 8) 

*****REWRITE  61  BY  { 27); 

62  /CLEARn(*CLOCKn(0[3]nQ[2]))/()[l>~0[l];  (2  5 8) 

*****SUBSTR  39  IN  9; 

63  /CLEARn~(CLEARn(iCLOCKn(Q[3]nQ[2])))/Q[l]M)[l];  (2  5 9) 

*****VE  56  Q[3)nO[2],Q[l]; 

64  /CLEARrw(CLEARn(*CLOCICn(0[3]nQ[2])))/Q[l]*O[l];  =(  /CLEARfw*CLOCK/X 
0[1>Q[1];  A /CLEARn(iCLOCKfw(Q[3]nQ[2]))70[l>Q[l];  ) 

****»TAUT  /CLEARn-v*CLOCK/Q(l>-Q[l];  A /CLEARn( *CLOCKrw(Qt3]nQ[2]) )/Q[X 
1>0[1]:  63:64; 

65  /CLEARn-viCLOCK/0[l]«^[l];  A /CLEARn( *CLOCICrw(Q[3]nQ[2]) )/Q[  1 >Q[  1 ]X 

: (259) 

****)»aE  65:#1; 

66  /CLEARfVv*CLOCK/Q[l]-Qtl];  (2  5 9) 

****»aE  65:#2; 

67  /CLEARn(iCLOCKrw(0[3]nQ[2]))/Q[l]M)[l];  (2  5 9) 

*****SUBSTR  43  IN  25; 

68  /CLEARn(CLEARn(iCLOCKn(Q[3]n(Qt2]nO[l]))))/Q[8J^Q[e];  (2  5 8 IIX 

) 

•****REWRITE  68  BY  { 27);  . 

69  /CLEARn(tCLOCICn(Q[3]n(Q[2)nQ[l])))/Q[0>«-<)(8];  (2  5 8 11) 

*****SUBSTR  43  IN  12; 
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70  /CLEARn-(CLEARn(*CLOCKn(Q[3]n(Q[Z]nQ[l]))))/Qt0]*Ote];  (2  5 0 12X 

) 

*****VE  56  O[3]n(O[Z]nO[l]).O[0]; 

71  /CLFARn~(CLEARn(*CLOCKn(Q[3]n(Q[2]nO[l]))))/Q[e]M)[®l;  =(  /CLEARfwX 
4CIOCX/Qr0]-Q[0]:  A /CLEARn(4CLOCKn^(Q[3]n(Ot2]nQ[l])))/O[0>Ot»];  ) 

*****TAUT  /CLEARn-viCLOCI<:/Q[0]*-Q[0];  A /CLEARn(iCLOCI(n~(Q[3]n(Q[2]nQ[  IX 
])))/Q[O>Q[0]:  70:71; 

72  /ClCARn^iCLOCK/OCaj-OEa];  A /CLEARn(*CLOCK(>~(Q[3]n(0[2)nOtl])))/0[X 

0>O[O];  (2  5 8 12) 

*****aE  72 : # 1 ; 

73  /CLEARn-4CLOCK/Q[0]*-Q[0];  (2  5 0 12) 

*****aE  72 : iZ ; 

74  /CLEARn(iCLOCKn-(Q[3]n(O[2]nQ[l])))/Q[0>Q[01;  (2  5 8 12) 

***»*VE  M3  CLEARniCLOCK,x,a,'va,a; 

75  ( /(CLEARn4CtOCt(:)nx/a*-~a;  a /(CLEARniCLOCK )n~x/a*-a ; )a  /CLEARn*CLOCX 
K/a*-(  xn^a  )u(~xna ) ; 

****»REWRITE  75  BY  { 21); 

76  ( /(ClEARn*CLOCK)nx/a-~a:  a /(CLEARn4CLOCK)fwx/a*-a;  )■  /CLEARnECLOCX 
K/a»-a»x: 

*****REWRITE  76  BY  ( T10B): 

77  ( /CLEARn(4CLOCKnx)/a-va:  a /CLEARo(*CL0CI(fKx)/a*-8;  )a  /CLEARn*CLOCX 
K/a*-a»x ; 

*****VI  77  X a; 

78  Vx  a.((  /CLEARn(4CLOCICnx)/a— a;  a /CLEARn( 4CLOCKfKx)/a-a;  )i  /CLEARX 
n ‘CLOCK /a«-a*x ; ) 

*****aI  (45  60 ) ; 

79  /CLEARn(4CLOCKnQ[3])/Q[2]*-vQ[2];  A /CLEARn(*CLOCKn~0[3])/0[2>0[2]X 

: (256) 

*****REWRITE  79  BY  { 78); 

00  /CLEARnlCLOCK/0[2>-0[2]»0[3]!  (2  5 6) 


»Al  (62  67); 


81  /CLEARn(*CLOCKn(Q[3]nO[2]))/Q[l>-*Q(l];  A /CLEARn( 4CLOCKfw(Q[3]nQ[X 

2J))/Of  1>0[1];  (2  5 8 9) 


‘REWRITE  01  BY  ( 78); 


02  /CLEARn4CLOCK/Q[I]-0{l]*(0(3]nQ[2]);  (2  5 8 9) 
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***»*VE  T7B  0[3],Q[2]; 

83  (Q[3]nO[23)=(Q[2]nO[33) 

*****SUBSTR  83  IN  82; 

8A  /CLEARn*CLOCK/0[13*-Q[l>(0[Z3n0[3J):  (2  5 8 9) 

*****a1  (69  74); 

85  /CLEARn(*CLOCKn(Q[33n(Q[23nQ[13)))/O[e3‘-~O[0];  a /CLEARn(  iCLOCKn-v(X 

O[33n(Q[23nQ[l3)))/Q[03-O[03:  (2  5 8 11  12) 

*****REWRITE  85  BY  { 78); 

86  /CLEARn*CLOCK/Q[03-O[03»(Q[33n(O[2]nQ[l]));  (2  5 8 11  12) 

*****VE  T7B  0[33.Q[2]nQ[l]; 

87  (Q[33n(0[23nQ[13))=((0[23n0[l])nQ[33) 

*****SUBSTR  87  IN  86; 

88  /CLEARniCLOCK/O[0]-Q[0>((O[2]nOtl])nQ[3]);  (2  5 8 11  12) 

*****VE  T7B  Q[23.Q[1]: 

89  (Q[23nQ[13)=(Q[13nQ[23) 

*****SUBS1R  89  IN  88; 

90  /CLEARn*CLOCK/Q[03»-O[03«((O[13nO[2])nQ[3]);  (2  5 8 11  12) 

*****aI  (90  84); 

91  /CLEARfHCLOCK/Q[03^Q[03*((Q[13nQ[23)nQ[33);  A /CLEARniCLOCK/Q[  1 ]-0X 

[13*(0[23nQ[33);  (2  5 8 9 11  12) 

****»aI  (91  80); 

92  ( /CLEARniCLOCK/Q[03-O[03»((Q[13nQ[23)nQ[33):  A /CLEARniCLOCK/Q[  1 ]^X 

0[13»(Q[23nQ[33):  )a  /CLEARniCLOCK/0[2]-0[23*Q[33:  (2  5 6 8 9 11  12) 

*****aI  (92  22) ; 

93  ((  /CLEARn*CLOCK/Q[03*-Q[03*((Q[l]nO[23)nO[3]);  a /CLEARniCLOCK/0[  1 ]X 
-0[  13»(0[23n0[33);  )a  /CLEARniCLOCK/Q[23«-0[2]*Q[3]:  )a  /CLEARniCLOCK/QX 
[3]— Q[33;  (2  5 6 8 9 11  12) 

*****REWRITE  93  BY  { M6); 

94  /CLEARniCLOCIC/((Q[0]&Q[l])&Q[2])&Q[3]-(((Q[0>((Q[l]nQ[2])nQ[3]))&X 

(Q[13«(0[2]nQ[33)))&(Q[23»Q[3]))«.~Q[3]:  (2  5 6 8 9 11  12) 

*****REWRITE  94  BY  { A6}; 

95  /CLEARn»CLOCK/((O[03&Q[l])&O[2])«.O[3]-(((O[0]a>O[l])atO[2])a<O[3])+l;X 
(2  5 6 8 9 11  12) 


asoMaai 
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***»*REWRITE  95  BY  CONCATENATE; 

96  /CLEARntCLOCK/0t«:3]-Q[®:3]+l;  (2  5 6 8 9 11  12) 

*****aI  ( 73  66) ; 

97  /CLFARn-«CLOCK/Q[0]-O[0]:  a /CLEARrw*CLOCK/0[  1 ]-0[  1 ]:  (2  5 8 9 IX 

2) 

*****aI  (97  59); 

98  ( /CLEARn-iCLOCK7O[0]-O[0]:  A /CLEARn~tCLOCK/Q[  1 >0[  1 ];  )a  /CLEARn~X 

ACLOCIC/0[2]-Q[2];  (2  5 6 8 9 12) 

*****aI  (98  3); 

99  ((  /CLEARn~iCLOCK/0[8>0[«]:  A /CLEARrw*CLOCK/Q[  1 ]«-Q[  1 ];  )a  /CLEARnX 
-iClOCK/Q[2>0[2];  )a  /CLEARn~tCL0CIC/Q[3]-Q[3];  (2  3 5 6 8 9 12) 

<t****REWRITE  99  BY  { M6); 

100  /CLE ARn- *CL0CK:/(  (Q[ 0 ]&Q[  1 ] )«<Q[ 2 ] )8iQ[ 3 >(  (Q[ 0 ]&0[  1 ] )«<Q[ 2 ] )&Q[ 3 ] ; X 
(2  3 5 6 8 9 12) 

*****REWRITE  100  BY  CONCATENATE; 

101  /CLEARn-v*CLOCK/O[0:3>O[0:3];  (2  3 5 6 8 9 12) 
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For  our  last  example  we  have  a multiplier  circuit  built  using  some  MSI 
components.  The  circuit  diagram  Is  in  Figure  12.1.  The  0-bit  operands  are  inputs 
X and  Y,  and  the  1 6-bit  product  will  be  in  the  Z register.  When  the  LOAD  signal  Is 
low  the  control  counter,  DONE  flip-flop,  and  high  order  bits  of  the  Z register  are 
cleared.  A downwards  tiansition  In  the  CLOCK  at  this  time  will  put  the  X operand 
into  the  W register  and  the  Y operand  Into  the  low  order  bits  of  the  Z register. 


The  actual  multiplication  sequence  takes  place  while  LOAD  Is  true.  On 
upwards  transitions  in  CLOCK  the  counter  Is  incremented.  Downwards  CLOCK 
transitions  control  the  adding  and  shifting  operations.  When  the  low  order  bit  of 
tlie  counter  is  true  the  contents  of  the  overflow  bit  and  the  Z register  will  be 
sliifted  right.  When  It  is  false,  the  high  order  bits  of  the  Z register  will  be  set  to 
the  sum  of  themselves  and  the  W register  If  the  least  significant  bit  of  the  Z 
register  is  true.  The  overflow  bit  is  Intended  to  function  as  the  most  significant 
bit  in  the  Z register  before  shifting.  After  this  shifting  and  adding  goes  on  for  1 6 
clock  cycles,  the  transition  from  1 6 to  0 in  the  counter  will  cause  the  DONE  flag 
to  be  set.  The  DONE  flag  will  inhibit  the  clock  pulses  from  changing  the  product  in 
the  Z register. 


/■vLOAD/  OV&Z[0:7>0; 

/-vLOAD/  Q[0:3]-0; 

/■vLOAD/  OONE*-0: 

/■vLOADniCLOCK/  W[0:7hX[0:7]; 
/~L0ADn*CL0CK/  Z[8:15>Y[0:7]; 


(57) 

(40) 

(50) 

(70) 

(105) 


/LOAOntCLOCK/  Q[0:3]‘-O[0:3]+l;  (106) 

/LOADni(Q[0:3]«15)/  DONE-l;  (114) 

/((LOADniCLOCK)n-DONE)nO[3]/  OV«.Z[0:15>0&OV8.Z[0:14];  (162) 

/((LOAOn*CLOCK)n-DONE)n(vQ[3]nZ[15])/ 

OV«>Z[0:7>carry(W[0:7],Z[0:73,0)&(W[0:7>Z[0:7]+0);  (197) 


/ ( ( LOAOn  * CLOCK) n^DONE ) n( ~Q[ 3 ]fwZ[ 1 5 ] ) / 

OV«t2[0;7>0«tZ[0:7];  (215) 

/((LOADntCLOCK)fVvDONE)fwO[3],'  Z[8: 15>Zt8: 15];  (227) 

/-((*LOADn-vCLOCK)u(-vLOADn*C  LOCK ) ) /W[  0 : 7 >-W[  0 : 7 ] ; (235) 

/LOADfwtCLOCK/  Ot0:3]-Q[0:3];  (236) 

/LOADn~MO[0:3>15)/  DONE-DONE;  (239) 

/LOADfw( ( iCLOCKn-DONE )u(-CLOCKn*OONE ) )/ 

OV8i2[0:15]-OV8iZ[0:15]:  (260) 


In  the  above  goals  the  first  group  represents  the  load  sequence,  the  second 
group  Is  the  multiply  sequence,  and  the  last  group  has  some  of  the  more  important 
feedback  states.  Although  this  proof  Is  260  steps  long  most  of  it  Is  very 
straightforward.  The  first  61  steps  were  needed  just  to  get  the  component 
definitions  into  the  proof  checker.  Some  of  the  goals  were  obtained  In  as  little  as  ■ 
one  step.  The  second  goal  (step  40)  was  obtained  directly  from  an  Input 
assumption. 
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*****OECLARE  INDCONST  LOAD, CLOCK, X,Y,Z,W,S,0,LOAOX,LOAOY, DONE; 
*****DECLARE  INDCONST  A,B,C,0,E,G,H,CLK,OV; 

**»**ASSUME  LOADX— (LOADuCLOCK);  ; 

1 LOADX«-~(LOADuCLOCK):  (1) 

*****ASSUME  LOADY*-~LOAO : ; 

2 LOADY-~LOAD ; ( 2 ) 

**»*i>ASSUHE  Ul/V[0:3]*-((B8iB)&0)8iB;  ; 

3 /~1/Wt0:3]-((B&0)«.0)&0;  (3) 

*****ASSUME  /lntLOADX/W[0:3]*-X[0:3]; 

4 /lntLOADX/M[0:3]-X[0:3];  (4) 

****»ASSUME  /ln-vtLOADX/W[0:3>-Wt0:3];  ; 

5 /ln-vtLOAOX/Wt0:3]-W[0:3];  (5) 

*****ASSUME  /~1/W[4:7>((0&0)«i0)&0:  ; 

6 /■vl/W[4:7]-((0&0)&0)«i0;  (6) 

im***ASSUME  /lntLOADX/W[4:7hX[4:7];  ; 

7 /lntLOAOX/W[4:7]-X[4:7];  (7) 

*****ASSUME  /ln'vtLOAOX/W[4:7]*-W[4:7];  ; 

8 /ln-tLOADX/W[4:7>W[4:7]:  (8) 

*****ASSUME  S[0:3XW[0:3]+Z[0:3])+E;  ; 

9 S[0:3>(W[0:3]+Z[0:3])+E;  (9) 

*****ASSUME  O-carry(W[0:3],Z[0:3],E);  ; 

10  D*-carry(W[0;3],Z[0:3],E);  (10) 

*****ASSUME  S[4:7>(W[4:7]+Z[4:7])+e;  ; 


17  /ln^LOAD/OV-0;  (17) 

*****ASSUHE  /( lnLOAD)ntC/OV«-B;  ; 

18  /( lnLOAD)ntC/OV*-B;  (18) 

**»»»ASSUME  /( lnLOAO)n-vtC/OV-OV;  ; 

19  /( lnLOAO)n~tC/OV-OV:  (19) 

*****ASSUME  /-LOAD/Z[0:3]-((0&0)&0)&0:  ; 

Ze  /-LOAD/Z[0:3>((0&0)&0)&0;  (20) 

*****AS5UME  /(LOADniCLK)nQ[3]/Z[0:3>OV&Z[0:2];  ; 

21  /(LOADniCLK)nO[3]/Z[0:3]-OV8.Z[0:2];  (21) 

*****ASSUME  /((LOADniCLIi:)n~Q[3])nZ[15]/Z[0:3]-S[0:3];  ; 

22  /((LOAOniCLK'n-Q[3])nZ[15]/Z[0:3]-S[6:3];  (22) 

****i*ASSUME  /((LOADn*CL(()n^Q[3])n-Z[15]/Z[0;3>Z[0:3];  ; 

23  /((LOADn*CLK)n~Q[3])n-Z[15]/Z[0:3>Z[B:3];  (23) 

*****ASSUME  /LOADn-vtCLK/Z[0:3]«-Z[0:3]:  ; 

24  /LOADn~iCLK/Z[0:3]»-Z[0:3];  (24) 

*****ASSUME  /■vLOAD/Z[4:7]-((0«(0)&0)&0:  ; 

25  /~LOAO/Z[4:7X(0&0)&0)&0;  (25) 

*»*»*ASSUME  /(LOA0ii*CLK)n0[3]/Z[4:7>Z[3]4Z[4:6]:  ; 

26  /(LOADniCLK)nQ[3]/Z[4:7>Z[3]«.Z[4:6];  (26) 

**»»*ASSUME  /((LOAOniCLK)n~Q[3])nZ[15]/Z[4:7>S[4:7];  ; 

27  /((LOADniCLK)fVvQ[3])nZ[15]/Z[4:7]*-S[4:7]:  (27) 

*****A5SUME  /((LOADniCLK)n~Q[3])n-Z[15]/Z[4:7>-Z(4:7];  ; 

28  /((LOADniCLK)n~Q[3])n~Ztl5]/Z[4:7]-2[4:7];  (28) 

•••••ASSUME  /LOAOfw*CLK/Z[4:7]«-Z[4:7];  ; 
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29  /LOADn~iCLIC/Z[4:7>Z[4:7]:  (29) 

*****ASSUME  /<vl/Z[8:llX(0M)ai0)&0:  ; 

30  /•vl/Z[8:ll]-((0&0)&0)&0;  (30) 

***»*ASSUME  /(lniCLK)nQ[3]/Z[8:ll]-Z[7]&Z[8:10];  ; 

31  /(lniCLK)nO[3]/Z[8:ll]-Z[7]&Z[8:10];  (31) 

*****ASSUME  /((ln*CLK)n-Q[3])nLOADY/Z[8:ll>Y[0:3];  ; 

32  /((ln*CLK)n~Q[3])nLOADY/Z[8;ll]-Y[0:3];  (32) 

*»***ASSUME  /((lniCLK)n^Q[3])rwL0A0Y/Z[3:ll]*-Z[8:ll]:  ; 

33  /((lniCLK)n^Q[3])n-L0ADY/Z[8:ll]-Z[8:lJ];  (33) 

*****ASSUME  /ln~iCLK/Z[8:n>Z[0:ll]:  ; 

34  /ln~iCLK/Z[8:ll]-Z[8:ll];  (34) 

**»**ASSUME  /-l/Z[12:15]-((0&0)&0)&0:  ; 

35  /~1/Z[  12:15>((0&0)8.0)&0:  (35) 

*****ASSUME  /(ln*CLK)nO[3]/zri2:15]-Z[113&Z[12:14]:  ; 

36  /(ln*CLK)nQ[3]/Z[12:15>Z[ll]&Z[12:14]:  (36) 

*****AS5UME  /((ln*CLK)n-vO[3])nLOADY/Z[12:15>Y[4;7];  ; 

37  /((lniCLK)n-vQ[3])nLOADY/Z[12:15>Y[4:7];  (37) 

**»**ASSUME  /((lniCLK)n~0[3])n~LOA0Y/Z[12:15>Z[12:15];  ; 

38  /((lrHCLK)n-vQ[3])n~LOADY/Z[12:15]-Z[12:15];  (38) 

*****ASSUME  /ln-viCLK/Z[12:15>Z[12:15]:  ; 

39  /ln-iCLK/Z[12:15]-Z[12:15];  (39) 

**«***ASSUME  /'vLOAD/O[0:3X(0&0)&0)&0;  ; 

40  /-vLOAD/Q[0:3X(0&0)&0)&0;  (40) 

****»ASSUME  /(LOADn-l)ntCLOCK/Q[0:3X(l&l)&l)&l:  ; 

41  /(LOADn~l)ntCLOCK/Q[0:3X(l&l)&l)&l;  (41) 
*****ASSUME  /(LOADn^l)n-vtCLOCK/Q[0:3>Q[0:3];  ; 

42  /(LOADn~l)a~tCLOCK/Q[0:3>O[0:3];  (42) 

****»ASSUME  /(((LOADnl)nl)nl)ntCLOCK/O[0:3>Q[0:3]+l;  ; 

43  /(((LOADnl)nl)nl)ntCLOCK/Q[0:3]-Q[0:3]+l;  (43) 
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*»***ASSUME  /(LOADnl)fw((  lnl)ntCLOCK)/Q[0:3]*-Q[0:3];  ; 

44  /(LOADnl)rvv((lnl)ntCLOCK)/O[0:3]«-Q[0:3];  (44) 

*****ASSUME  H«-Q[0:3]-15;  ; 

45  H«-O[0:3]-15;  (45) 

*****ASSUME  G-~H;  ; 

46  G— H;  (46) 

*****ASSUME  /-1/DONE-l;  ; 

47  /-1/DONE-l;  (47) 

*****ASSUME  /lfVvLOAO/DONE«-0;  ; 

48  /ln~LOAO/DONE-0;  (48) 

*<n»»*ASSUME  /(lnLOAD)ntG/OONE-l:  ; 

49  /(lnLOAD)nfG/DONE-l:  (49) 

*****ASSUME  /(lnLOAO)n'vtG/OONE«-OONE;  ; 

50  /( lnLOAO)n-vtG/PONE»-DONE;  (50) 

*****ASSUME  CLK»-CL0CKuD0NE:  ; 

51  CLK-CLOCICuOONE:  (51) 

*****aI  (20  25); 

52  /-LOAD/Z[0:3]-((0&0)«<0)&0:  A /<vLOAD/Z[4:7X(0&0)&0)&0;  (20  25) 

(»**»*REWRITE  52  BY  { M6); 

53  /■vLOAD/Z[0:3]&Z[4:7]-(((0&0)&0)&0)&(((O&0)&0)&0);  (20  25) 

*****REWRITE  53  BY  CONCATENATE; 

54  /~LOAD/Z[0:7X((0&0)&0)&0)&(((0&0)at0)&0);  (20  25) 

*****REWRITE  17  BY  REDUCE; 

55  /-LOAD/OV-B;  (17) 

*****aI  (55  54); 

56  /^LOAD/OV<-0;  a /<vLOAD/Z[0:7X((0&0)&0)&0)&(((0&0)M)&0);  (17  28X 

25) 

***<(*REWRITE  56  BY  ( M6); 

57  /'vLOAD/OV&Z[0:7>0&((((080)&0)&0)&(((0&0)&0)&0));  (17  20  25) 

•****REWRITE  48  BY  REDUCE; 
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58  /~LOAD/DONE*-0:  (48) 

*****VE  M2  LOAOX,-v(LOADuCLOCK); 

59  LOADX^^dOADuCLOCK);  dOADXs-CLOADuCLOCK) 

*****TAUT  LOADX=..(LOAOuCLOCK)  1,59; 

60  LOAOX=~(LOAOuCLOCX)  (1) 

*****REWRITE  4 BY  REDUCE; 

61  /tLOADX/W[0:3>X[0:3];  (4) 

♦ ***i*REWRITE  7 BY  REDUCE; 

62  /tLOADX/W[4:7>X[4:7];  (7) 

*****aI  (61  62); 

63  /tLOADX/W[0:3>X[0:3];  A /tLOADX/W[4;7]-X[4;7];  (4  7) 

*****REWRITE  63  BY  { M6); 

64  /tLOADX/W[0:3]&W[4:7]-X[0:3]*X[4:73;  (4  7) 

*****REWRITE  64  BY  CONCATENATE; 

65  /tLOADX/W[0:7]-X[0:7];  (4  7) 

*****SUBSTR  60  IN  65; 

66  /t~(LOADuCLOCK)/W[0:7]-X[0:7];  (147) 

**«**REWRITE  56  BY  { T14A); 

67  /t(.vLOAOftvCLOCX)7W[0;73»-X[0;73;  (14  7) 

*****REWRITE  67  BY  TRANS; 

68  /(iLOADn-vCLOCK)u(~LOAOn«CLOCK)/W[0;7]-X[0:7];  (14  7) 

♦♦***REWRITE  68  BY  { M5); 

69  /dOADn-vCLOCK/W[0:7>X[0:7];  A /~LOAOn*CLOCIC/W[0:7]-X[0:7]; 
7) 

*****aE  69:#2: 

70  /^LOADn*CLOCK/W[0:7>X[0:7];  (14  7) 

*****VE  M2  LOADY.^LOAD; 

71  LOAOY«-~LOAD;  sLOADYs-LOAD 
»****TAUT  LOADYs^LOAO  2,71; 

72  LOADY=~LOAO  (2) 
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*****REWRITE  32  BY  REDUCE; 

73  /(*CLKn-Q[3])nL0A0Y/Z[8:ll>Y[e:3];  (32) 

*****REWRITE  37  BY  REDUCE; 

74  /(*CLICn-Q[3])nLOADY/Z[12:15]«-Y[4:73;  (37) 

*****aI  (73  74); 

75  /(*CLKn^O[3])nLOADY/Z[8:ll>Y[0;3];  A /( ♦CUf>vO[3])nLOAOY/Zt  12: 15]X 

«-Y[4:7];  (32  37) 

*****REWRITE  75  BY  | MB); 

76  /(iCLt<:n-Q[3])nLOADY/Z[8:ll]AZ[12:15]-Y[0:3]«.Y[4:7];  (32  37) 

*****REWRITE  76  BY  CONCATENATE; 

77  /(iCLKn-vO[3])nLOADY/Z[8:15]-Y[0:7];  (32  37) 

*****SUBSTR  72  IN  77; 

78  /(tCLKn-vQ[3])n-LOAD/Z[8:15]-Y[0:7];  (2  32  37) 

*****VE  M6  -LOAD,Q[0:2],(0&0)&0,Q[3],0; 

79  ( /-LOAD/Q[0:2XB&0)at0;  A /-LOAD/Q[3>0;  )•  /«LOAD/Q[0:2]&O[3X(0* 

&O)&e)&0; 

»*«**REWRITE  79  BY  CONCATENATE; 

80  ( /-LOAO/O[0:2X0&0)«i0;  a /-LOAO/Q[3>0;  )i  /«LOAO/O[*:3X(e8i0)m 

)&0; 

*****SUBST  80  IN  40; 

81  /-LOAD/O[0:2Xe&0)&0;  A /~LOAO/Q[3>0;  (40) 

*****aE  81:#2; 

82  /-LOAD/O[3>0;  (40) 

i 

*****VE  HUB  -LOAD,Q[3],0; 

83  /-LOAO/O[3]-0;  3(-vLOADrwQ[3])=(-LOADfw0) 

*»***TAUT  (~LOADfwQ[3])*(vLOADfw0)  82:83; 

84  (-LOADfVvQt3])  = ('-LOAOfVv0)  (48) 

*****REWRITE  84  BY  REDUCE; 

85  (-vLOADn-vOt3])=-LOAD  (40) 

*****REWRITE  78  BY  { T10B}; 

86  /*CLKn(~Q[3]rv-LOAD)/Z[8:15X[»:7];  (2  32  37) 
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*****VE  T7B  -0[3],-LOAD: 

87  (-0[3]n-LOAD)=(-LOADn~Q[3]) 

****»SUBSTR  07  IN  86; 

38  /*CLKn(vLOADn-Q[3])/Z[8:15]-V[e:7];  (2  32  37) 

*****SUBSTR  85  IN  88; 

89  /iCLKn~LOAO/Z[8:15]-Yte:7):  (2  32  37  48) 

**»**VE  T7B  *CLK,-LOAO; 

90  ( iCLKn-vLOAD)  = (~LOAOn*CLK) 

*****SUBSTR  90  IN  89; 

91  /-LOADniCLK/Z[8:15]-Y[0:73;  (2  32  37  40) 

***»*VE  M2  CLK.CLOCKuDONE; 

92  CLK-CLOCKuOONE;  =CLK»(CLO«uOONE) 

*****TAUT  CLK=(CLOCK:uDONE)  51,92; 

93  CLK=(CLOCKuDONE)  (51) 

*****SUBSTR  93  IN  91; 

94  /-LOAC)ni(CLOCKuOONE)/Zt8:15>-Y[0:7];  (2  32  37  40  51) 

*****REWRITE  94  BY  TRANS; 

95  /-LOAOn((4CLOCKn-vDONE)u(*CLOCKn*DONE))/2[0:15>Y[0:7);  (2  32  37  X 
40  51) 

****»REWRITE  95  BY  { TllA); 

96  /(~LCADn(*CLOCKn-DONE))o(-LOADn(vCLOCKn*DONE))/Z[8:15Mt0:7];  (X 
2 32  37  40  51) 

*****REWRITE  96  BY  { M5}; 

97  /~LOADn(*CLOCKn-DONE)/Z[8:15>Y[0:7]:  A /-LOADn(-CLOCICn*DONE)/Z[0:X 

15]-Y[0:7];  (2  32  37  40  51) 

*****aE  97:#1; 

98  /-LOAOn(*CLOCKrvvDONE)/Z[8:15M[0:7];  (2  32  37  40  51) 

*****VE  T7B  * CLOCK, -DONE; 

99  (4CLOCKn~DONE)=(-DONEn*CLOCK) 

*****SUBSTR  99  IN  98; 

100  /-vLOADn(~DONEniCLOCK)/Z[8:15M[0:7];  (2  32  37  48  51) 
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*****REWRITE  lee  BY  { TIBBR); 

101  /(-LOADn-vOONE)n*CLOCK/2[8;15]«-yfl:7];  (2  32  37  40  61) 

*****VE  HUB  'V load. DONE, 0; 

102  /~LOAD/DONE*-0;  3(~LOADrwDONE  )»(-vLOADfW0) 

*****TAUT  ('vLOADn^DONE)  = (~LOADn~e)  58,102; 

103  (~LOADn-*DONE)=(~LOADn~0)  (48) 

*****REWRITE  103  BY  REDUCE; 

104  (~LOADn~DONE)=~LOAD  (48) 

)«****SUBSTR  104  IN  101; 

105  /-LOADn*CLOCK/Z[8:15>Y[0:7];  (2  32  37  40  48  51) 

*****REWRITE  43  BY  REDUCE; 

106  /LOAOntCLOCK/Qt0:3]*-Q[0:3]+l;  (43) 

*****VE  M2  H,O[0:3]»I5; 

107  H^Q[0:3>15;  3Hs(Q[0 :3]-15) 

*****TAUT  H=(O[0:3]«15)  45,107; 

108  H=(O[0;3>15)  (45) 

*)nn**VE  M2  G.'vH; 

109  G«-^H;  3G=~H 
*****TAUT  G=~H  46,109; 

110  G=-H  (46)  . 

*****SUBSTR  108  IN  110; 

111  G=-(O[0:3]-15)  (45  46) 

*****REWRITE  49  BY  REDUCE; 

112  7LOADntG/DONE-l;  (49) 

*****SUBSTR  111  IN  112; 

113  /LOADnt~(Q[0:3>15)/DONEfl;  (45  46  49) 

*****REWRITE  113  BY  TRANS; 

114  /LOADn*(Q[0:3]«15)/OONE*-l;  (45  46  49) 

*****REWRITE  /LOADn(xnMCLOCKuDONE))/a«-y:  BY  TRANS; 

115  /LOAOn(xn*(CLOCKuDONE))/a«-y;  a /LOADn(xn((«CLOCKrwDONE)u(«CLOCKn«« 
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DONE)))/a-y: 

*****REWRITE  115  BY  { TllA); 

116  /LOAOn(xnMCLOCKoOONE))/a*y;  ■ /(LOADn(xn(*CLOCKo~DOHE)))u(LOAOn(X 
X n ( LOCKn  * DONE ) ) ) /a-y ; 

*****REWRITE  116  BY  { M5}; 

li;  /LOADn(xni(CLOCKuDONE)>/a-y;  i(  /LOAOn(xn(*CLOCICfVvDONE))/a-y;  a /X 
LOADn(xn(~CLOCiCn*DONE))/a*-y;  ) 

*****VE  T7B  x.MCLOCKuOONE): 

118  ( X n * ( C LOCK  uDONE ))=(*( CLOCKoOONE ) nx ) 

****)*SUBSTR  118  IN  117; 

119  .7J.OAOn(*(CLOCKuOONE)nx)/a-y;  i(  /LOADn(xn( «CLOCKf>~DONE) )/a«-y;  a /X 
LOADn(xn(~CLOCKn*DONE))/a-y;  ) 

*****VE  T7B  x,*CLOCKfVvDONE; 

120  ( xn( iCLOCKn^DONE ) ) = ( ( ♦CLOCKn~DONE )nx ) 

*****SUBSTR  120  IN  119; 

121  /LOADn(i(CLOCKuDONE)nx)/a-y;  i(  /LOAOn( ( *CLOCKn~DONE)nx)7a-y;  a /X 
LOAOn(xn(-vCLOCKn*DONE))/a*-y;  ) 

*****SUBST  93  IN  121; 

122  /LOAOn(4CLKnx)/B«-y;  «(  /LOAOnU ‘CLOCK rwOOME)nx)/a«-y;  A /LOADn(xn(X 

■vCLOCKniDONE))/a-y;  ) (51) 

*****REWRITE  122  BY  { TIBBR); 

123  /(LOADn*CLK)nx/a«-y;  a(  /((LOADn*CLOCK)fKOONE)nx/a«-y;  a /((LOAOnx)X 

n-vCLOCK)n*DONE/a-y:  ) (51) 

*****vi  123  X a y; 

124  Vx  a y.(  /(LOADniCLK)nx/a«-y;  a(  /((LOADn‘CLOCK)rvvDONE)nx/a«-y;  a /(X 

(LOAOnx)n~CLOCK)n*DONE/a*-y;  ))  (51) 

*****aI  (21  26); 

125  /(LOADn*CLK)nQ[3]/Z[0:3]*^VAZ[8:2];  A /(LOADn*CLK)nQ[3]/Z[4:7]-Z[X 

3]8(Z[4:6];  (21  26) 

*****REWRITE  125  BY  { M6); 

126  /(LOADn*CLK)nO[3]/Z[0:3]«[4;7>(OV&Z[0:2])A(Z[3]&Z[4:6]);  (21  X 

Z6) 

*****REWRITE  126  BY  ( 05} ; 

127  /(LOADniCLK)nO[3]/2[e:3]4Z[4:7]M)V4(Z[0:2]&(Z[3]4Z[4:6]));  (21  X 

26) 
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*****REWRITE  127  BY  CONCATENATE: 

128  /(LOADniCLK)nO[3]/Z[e:7]-OV8(Z[8:6];  (21  26) 

*****aI  (31  36); 

129  /(lniCLK)nO[3)/Z[8:ll]-Z[7]&Z[0:18];  A /( ln*CLK)nO[ 3]/Z[ 12 : 15]-Z[X 

11]8(Z[  12:14];  (31  36) 

*****REWRITE  129  BY  { M6); 

130  /(lrnCLK)nQ[3]/Z[8:ll]4Z[12:15HZt7]AZ[8:l«])*(Z[ll]atZtl2:14]);  X 
(31  36) 

*****REWRITE  130  BY  REDUCE; 

131  /4CLKnQ[3]/Zt8:ll]8.Z[12:15MZ[7]&Z[8:10])&(ZCll]*Z[12;14]);  (3X 

1 36) 

*****REWRITE  131  BY  CONCATENATE; 

132  /4CLKnQ[3]/Zt8:15]-Z[7:14]:  (31  36) 

*****VE  M10  4CLKnQ[3],LOAO,Z[8:15],Z[7:14]; 

133  /4CLKnQ[3]/Z[8:15>Z[7:14];  = /( 4CLKnO[ 3])nLOAD/Z[0: 15WC 7 : 14];  X 

*****TAUT  /(iCLt(nQ[3])nL0A0/Z[8:15>Z[7:14];  132:133; 

134  /(4CLKnQ[3])nLOAO/Z[8:15>Z[7:14];  (31  36) 

»****VE  T7B  4CLKnO[3].LOAD; 

135  ((iCLKnQ[3])nLOAD)=(LOADn(*CLICnQ[3])) 

*****SUBSTR  135  IN  134; 

136  /LOAOn(iCLKnO[3])/Z[8:15>Z[7:14];  (31  36) 

***»*REWRITE  136  BY  { T10BR): 

137  /(LOADniCLK)nQ[3]/Z[8;I5]*-Z[7:14];  (31  36) 

*****aI  (128  137); 

138  /(LOADn4CLK)nQ(3]/Z[e:7]*-OV&Z[0:6];  a /(LOAOn*CLK)nO[3]/Z[8:l5>-ZX 

[7:14];  (21  26  31  36) 

♦••••rewrite  138  BY  { M6): 

139  /(LOAOn4CLK)nQ[3]/Z[0:7]&Z[8!l5XOV«.Z[0;6])4Z[7;14];  (21  26  31X 

36) 

•••••rewrite  139  BY  { 05): 

140  /(LOADntCLK)nQ[3]/Z[0:7]&Z[0:15>OV&(Z[0:6]&Z[7:14]);  (21  26  SIX 

36) 
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*****REWRITE  140  BY  CONCATENATE; 

141  /(LOADniCLK)nQ[3]/Z[e:15>OV«iZ[e:14];  (21  26  31  36) 

*****REWRITE  18  BY  REDUCE; 

142  /LOADntC/OV*^B;  (18) 

*****VE  M2  C,~CLK; 

143  C— CLK;  dCs-CLK 
*****TAUT  Cs-vCLK  15,143; 

144  C=~CLK  (15) 

*****SUBSTR  144  IN  142; 

145  /LOADnt-vCLK/OV-B;  (15  18) 

*****REWRITE  145  BY  TRANS; 

146  /LOAOn»CLK/OV-B;  (15  13) 

*****VE  H2  B,(DnA)nZ[15]; 

147  B*-(DnA)nZ[15];  5Be((0nA)nZ[15]) 

*****TAUT  B»((OnA)nZtl5])  14,147; 

148  B=((DnA)nZ[153)  (14) 

*****SUBSTR  148  IN  146; 

149  /LOADn*CLIC/OV-(OnA)nZ[153;  (14  15  18) 

*****VE  M2  A,-vOt33: 

150  A--vO[33;  3As^0[33 
*****TAUT  A><vQ[33  13,150; 

151  A>vQ[3]  (13) 

*****SUBSTR  151  IN  149; 

152  /LOAOn*CLK/OV-(DfwQ[3J)nZ[153;  (13  14  15  18) 

***ft*VE  T7B  D,<vQ[33;  • 

153  (Dn-vO[33)=('vO[33nO) 

*****SUBSTR  153  IN  152; 

154  /LOADniCLK/OV-(-vQ[33nO)nZ[15];  (13  14  15  18) 
*****REWRITE  154  BY  { T10B}; 


! 
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155  /LOADn*CLK/OV-~Q[3]n(DnZ[15]):  (13  14  15  18) 

*****VE  M10  LOAOniCLK,Q[3],OV,~Q[3]n(DnZ[l5]); 

15C  /LOADniCLK/OV-vO[3]n(DnZ[15]);  = /(LOAOn*CLK)nQ[3]/OV«-~Q[3]n(OnZtX 
15]): 

*****TAUT  /(LOADn*CLIC)nQ[3]/OV«-'vQ[3]n(DnZ[15]);  155:156; 

157  /(LOADniCLK)nQ[3]/OV-~Q[3]n(DnZ[15]);  (13  14  15  18) 

*****REWRITE  157  BY  { MB); 

158  /(LOADniCLK)nQ[3]/OV«-0;  (13  14  15  18) 

*****aI  (158  141); 

159  /(LOAOniCLK)nQ[3]/OV-0;  a /(LOAOn*CLK)nQ[3]/Z[0;15>OV4Z[0;14];  X 
(13  14  15  18  21  26  31  36) 

*****REWRITE  159  BY  ( M6); 

160  /(LOADn*CLIC)nQ[3]/OVaiZ[0:15>0A(OVAZ[0:14]);  (13  14  15  18  21  26X 

31  36) 

*****REWRITE  160  BY  { 124); 

161  /((LOADniCLOCK)n~DONE)nO[3]/OV&Z[0:15>08t(OV&Z[0:14]);  A /((LOADnX 

Ot3])n-CIOCK)niDONE/OV8.Z[0:15>0&(OV&Z[0:14]);  (13  14  15  18  21  26  31X 

36  51  ) 

***^»aE  161:#1; 

162  /((LOADniCLOCK)n-vOONE)nQ[3]/OV&Z[e:15]-0*(OVAZ[0:14]);  (13  14  IX 

5 18  21  26  31  36  51) 

*****Al  (9  11); 

163  S[0;3]-(W[0;3]+Z[0;3])+E;  aS[4:7>(W[4:7]+Z[4;7])+0;  (9  11) 

*****REWRITE  163  BY  { M6>; 

164  S[0;3]&S[4:7]-((W[0:3]+Z[0:3])+E)ai((W[4:7]+Z[4:7])+0);  (9  11) 

**»**REWRITE  164  BY  CONCATENATE; 

165  sr0:7]-((W[0:3]+Z[0:3])+E)ai((W[4:7>Z[4:7])+0);  (9  11) 

»****VE  M2  E,carry(W[4:7],Z[4:7],0); 

166  E-carry(W[4;7],Z[4:7],0);  DE=carry(W[4:7),Z[4;7],0) 

*****TAUT  E=carry(W[4:7],Z[4:7],e)  12,166; 

167  E=carry(W[4:7],Z[4:7],0)  (12) 

****r*SUBSTR  167  IN  165; 

168  S[0:7]^((W[0:3]+Z[0:3])+carry(W[4:7],Z[4:7],e))&((W[4:7>Z[4:7])*0X 
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):  (9  11  12) 

*****VE  A4  W,Z,0,0,3,7: 

169  (((W[0:3]+Z[9;3])+carry(W[suc(3):7],Z[5'JC(3):7],0))4((W[suc(3):7]+X 
Z[suc(3):7])+0))=((W[0:7]+Z[0:7])+0) 

*****S1MPLIFY  ; 

170  (((W[0;3]+Z[9:3])+carry(W[4;7],Z[4;7],0))&((W[4;7]+Z[4:7])+0))«((WX 
[0:7]+Zt0:7])+O) 

*****SUBSTR  170  IN  168; 

171  S[0:7>(W[0:7]+Z[0;7])+0:  (9  11  12) 

*****VE  M2  S[0:7],(W[0:7]+2l0:7])+0; 

172  S[0:7>(W[0:7]+Z[0:7])+0:  .-5S[0:7h((W[0:7]+Z[0:7])+0) 

***»*TAUT  S[0;7]=((W[0:7]+Z[0:7])+0)  171:172; 

173  S[0:7]=((W[8:7]+Z[0:7])+0)  (9  11  12) 

*****aI  (22  27); 

174  /((LOADniCLK)n~Or3])nZ[15]/Z[0:3]-S[0:3];  a /((L0ADniCLK)fVvQ[3])nX 

Z[15]/Z[4:7]-S[4:7];  (22  27) 

*****REWRITE  174  BY  { M6); 

175  /((LOADniCLK)n~Q[3])n2[15]/Z[0:3]«.Z[4:7>S[0:3]8.S[4:7];  (22  27) 

*»***REWRITE  175  BY  CONCATENATE; 

176  /((LOAOn*CLK)n-Q[3])nZ[15]/Z[0:7>S[0:7];  (22  27) 

*****SUBSTR  173  IN  176; 

177  /((LOADniCLIC)n~O[3])nZ[15]/Z[0:7XW[0:7]+Z[0:7])+0;  (9  11  12  2X 

2 27) 

*****VE  M2  D,carry(W[0:3],Z[0:3],E); 

178  D*-carry(W[0:3],Z[0:3],E);  DD=carry(W[0:3],Z[0:3],E) 

• a**i»TAUT  O»carry(W[0:3],Z[e:3],E)  18,178; 

179  O=carry(W[0:3].Z[0:3],E)  (18) 

*****SUBSTR  167  IN  179; 

180  D=carry(W[0:3],Z[0:3],carry(W[4:7],Z[4:7],0))  (18  12) 

*****VE  A2  W, 2,0, 0,3, 7; 

181  carry(W[0:3],Z[0:3],carry(W[suc(3):7],Ztsuc(3)  :7],0)  )=carry(W[0;7]X 
.Z[0:7],0) 
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*****SIMPLIFY  ; 

182  carry(W[0:3],Z£0:3].carry(W[4:7],Z[4:7],0))«carry(W[e:7],Z[0:7],e)X 

*****SUBSTR  162  IN  180; 

183  D=carry(W[0;7],Z[0;7],0)  (10  12) 

*****REWRITE  152  BY  { T10B); 

184  /LOADn*CLK/OV«-On(~Q[3]nZ[15]);  (13  14  15  18) 

*****VE  T7B  0; 

185  Vy . (Dny )=(ynD) 

*****REV(RITE  184  BY  { 185); 

186  /LOAOn*CLN/OV*-(-vO[3]nZ[15])nD;  (13  14  15  18) 

*****VE  M10  LOADn*CLK,-Q[3]nZ[15],OV,(*Q[3]nZ[15])nD; 

187  /LOADniCLIC/OV-(-Q[3]nZ[15])nO;  a /(L0ADn*CLK)n(vQ[3]nZ[  15])/0V*-(~X 
0[3]nZ[ 15])nD: 

*****TAUT  /(LOADn*CLI()n(-Q[3]nZ[15])/OV«-(~0[3]nZtl5])nD;  186:187; 

188  /(LOADniCLK)n(~Q[3]nZ[15])/OV-(-vQ[3]nZ[15])nO;  (13  14  15  18) 

***(*»REWRITE  188  BY  { M7); 

189  /(LOADn*CLK)n(~Q[3]nZ[15])/OV«-D;  (13  14  15  18) 

*****REWRITE  189  BY  { T10BR}; 

190  /((LOADniCLK)fwO[3])nZ[15]/OV-D;  (13  14  15  18) 

***»*SUBSTR  183  IN  190; 

191  /((LOADn*CLK)fwQ[3])nZri5]/OV-carry(W[0:7],Z[0:7],0);  (10  12  13X 

14  15  18) 

*****aI  (191  177); 

192  /((LOADn*CLIC)rwQt3])nZ[15]/OV«-carry(W[0:7],Z[0:7J,0);  a /((LOAOn*X 

CLIC)n~O[3])nZ[15]/Z[0:7]-(W[0:7]+Z[0:7])+0;  (9  10  11  12  13  14  15  18  X 

22  27) 

*****REWRITE  192  BY  { M6); 

193  /((LOADniCLK)fVvQt3])nZ[15]/OV&Z[0:7>carry(W[8:7],Z[0:7],0)8i((W[0X 

:7]+Z[0:7])+0);  (9  10  11  12  13  14  15  18  22  27) 

•**»*VE  T10B  LOAOniCLK; 

194  Vy  z.(((LOAOniCLK)ny)nz)=((LOAOn*CLK)n(ynz)) 
a***aREWRITE  193  BY  ( 194); 
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195  /(LOADniCLK)n(~Q[3jnZ[15])/OV8tZt0:73-carry(H[9:7],Z[0:7],0)a.((W[0X 

: ’l+7[0;71)+0);  (9  10  11  1?  13  14  15  18  22  27) 

*****REWRITE  195  BY  { 124); 

196  / ( ( LOADn iCLOCK ) n-DONE ) n( -Q[  3 ]nZ[  1 5 ] ) /OVa<Z[ 0 : 7 >car ry ( Wt  0 : 7 ] , Z[  0 : 7X 

],0)a(((W[0:7]+Z[0:7])+0);  A /( ( LOADn(~Q[ 3]nZ[  15]) )n'vCLOCK )n*DONE/OV&Z[y. 
0;7]-carry(W[0:7],Z[0:7],0)&((W[0:7]+Z[0:7])+0);  (9  10  11  12  13  14  IX 

5 18  22  27  51) 

**;***aE  196;#1: 

197  / ( ( LOADn  iCLOCK ) n-vDONE ) n(  ~0[  3 ]nZ[  1 5 ] ) /OV8.Z[  0 : 7 3-carry  ( W[  0 : 7 ] , Zt  0 : 7X 

],0)&((W[0:7]+Z[0;7])+0);  (9  10  11  12  13  14  15  18  22  27  51) 

****»aI  (23  28); 

198  /((LOADn*CLK)n-O[33)n-Ztl5]/Z[0;33-Z[e:33;  A /( (LOADn*CLK)rvvO[33)X 

n-Z[15]/Z[4:7]-Z[4:7];  (23  28) 

*»***REWRITE  198  BY  { M6); 

199  /((LOADn*CLK)n~Q[3j)n~Z[15]/Z[0:3]a.Z[4:7]-Z[0:3]&Z[4:7];  (23  28X 

) 

*****REWRITE  199  BY  CONCATENATE; 

200  /((LOAOn*CLK)n~O[3])n-Z[153/Z[0:73-Z[0:7];  (23  28) 

*****VE  M10  LOADn*CLK,-Q[33n-Z[15],OV,('vO[3]nZ[15])nO; 

201  /LOADniCLK/OV-(-Q[3]nZ[15])nD;  a /(L0ADn*CLK)n(-vQ[3]n-Z[  15])/0V-(X 
-Q[33nZ[15])nO; 

*****TAUT  /(LOADniCLK)o(~0[33n~Z[15])/OV-(-0[33nZ[153)nO;  186,201; 

202  /(LOADniCLK)n(~0[33n'vZ[153)/OV-(-Q[33nZ[l5])nO;  (13  14  15  18) 

*****REWRITE  202  BY  ( T10BR); 

203  /((LOADn*CLK)n-0[33)n-Z[153/OV-(~Q[3]nZ[153)nO:  (13  14  15  18) 

*****VE  T7B  -0[3],Z[15]; 

204  (•vO[3]nZ[15])  = (Z[15]rwO[33) 

*****SUBSTR  204  IN  203; 

205  /((LOADr!iCLK)n-Q[3])n-Z[15]/OV-(Z[15]n-Q[33)nO;  (13  14  15  18) 

*****VE  T10B  Z[15]; 

206  Vy  z.((Z[153ny)nz)=(Z[15]n(ynz)) 

*****REWRITE  205  BY  { 206); 

207  /(( LOADn  4CLK)n~0[  33)  rwZ[153/OV-Z[153n(-Q[3]nD);  (13  14  15  18) 
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*****VE  MS  (LOADn*CLK)n~0[3],OV,~Z[15],'vQ[3]nO; 

208  /((LOADniClK)n~Q[3])fwZ[15]/OV«-v^Z[15]n(~Q[3]nO);  • /( (L0ADn4CLK)X 

n~Q[3])n'vZ[15]/OV-0; 

*****REWRITE  208  BY  REDUCE; 

299  /((LOADn*CLK)n~0[3])rwZ[l5]/OV-Z[15]n(vQ[3]nD)!  ■ /( (LOADn»CLK)fwX 

Q[3])nvZ[15]/OV-0: 

*****TAUT  /((LOADn*CLK)n~Q[3])fwZ[15]/OV«-0;  297,209; 

210  /((LOADniCLK)n~Q[3])n~Z[15]/OV*-0;  (13  14  15  18) 

*****aI  (210  200); 

211  /((LOADniCL<)n-vQ[3])n~Z[15]/OV-0;  A /( (LOAOn*CLIC)n^O[3])fwZ[  15]/ZX 
[OrZ^ZEO:?);  ( 13  14  15  18  23  28) 

*****REWRITE  211  BY  ( M6}; 

212  /((LOADniCLK)f)-O[3])n-vZtl5]/OVAZ[0:7>0&Z[0:7];  (13  14  15  18  23X 

28) 

(k****REWRITE  212  BY  ( 194); 

213  /(LOADn*CLK)n(-Q[3]n-Z[15])/OV&Z[0:7>O&Z[0:7];  (13  14  15  18  23% 

28) 

*****REWRITE  213  BY  { 124); 

214  /((LOADn*CLOCK)n-OONE)n(-vQ[3)n-vZ[15])/OVa.Z[O:7>0&ZtO:7];  a /((LOX 

ADn(-Q[3]n~Z[  15]))n-vCLOCK)n*DONE/OV&Z[O:7>O&Z[0:7];  (13  14  15  18  23X 

28  51  ) 

*****aE  214:#1; 

215  /((LOADn*CLOCK)fVvOONE)n(-vQ[3]n<vZ[15])/OV&Z(8:7]«-08Z[0:7];  . (13  IX 
4 15  18  23  28  51) 

*****REWRITE  33  BY  REDUCE; 

216  /( *CLICn~Q[3])n-L0ADY/Z[8:ll>Z[8:ll];  (33) 

*****REWR1TE  38  BY  REDUCE; 

217  /( iCLKn-vQ[3])rwLOADY/Z[12:15>Z[12:153;  (38) 

*****aI  (216  217); 

218  /( *CLKr>vQ[3])fVvLOADY/Z[8:ll]*-Z[8:ll];  A /( *CLKfwQt3])fVvLOADY/Z[  12X 

: 15>Z[  12:15];  (33  38) 

*****REWRITE  218  BY  ( H6}; 

219  /(*CLKn~Q[3])rvvLOADY/Z[8:ll]&Z[12:15>Z[8:ll]4Z[12:15];  (33  38) 

**»»»REWRITE  219  BY  CONCATENATE; 
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220  /(iCLKn~Q[3])n~LOADY/Z[8:15]-Z[8:15];  (33  38)  ( 

*****SUBSTR  72  IN  220; 

221  /(*CLKn^Q[3])n--LOAD/Z[8:15]-Z[8:15];  (2  33  38) 

*****REWRITE  221  BY  REDUCE; 

222  /(*CLKn~Q[3])nL0A0/Z[8:15]-Z[8:15]:  (2  33  38) 

*****VE  T7B  *CLKn~Q[3],L0AD;  ; 

223  ((*CLKn-Q[3])nLOAD)s(LOADn(*CLKfVvQ[3])) 

*****SUBSTR  223  IN  222; 

224  /LOADn(iCLKn~Q[3])/Z[8:15]-Z[8:15];  (2  33  38) 

I *****REWRITE  224  BY  { T10BR); 

225  /(LOADniCU)n~0[3]/Z[8:15>Z[8:15];  (2  33  38) 

*****REWRITE  225  BY  { 124); 

226  /((LOADniCLOCK)n-OONE)n-0[3]/Z[8:15]-Z[8:153;  A /( ( LOADn~Q[  3])rvvCX 

LOCK)nADONE/Z[8:15]-Z[8:15];  (2  33  38  51) 

*****aE  226 :#1 ; 

227  /((LOADntCLOCK)n~DONE)nvQ[3]/Z[8:15]«-Z[8:15];  (2  33  38  51) 

*****REWRITE  5 BY  REDUCE; 

228  /~tLOADX/W[0:31-W[0:3];  (5) 

*****REWRITE  8 BY  REDUCE; 

229  /~tLOADX/W[4:7]-W[4:7]:  (8) 

*****aI  (228  229); 

230  /-tLOADX/W[0;3]-W[0:3];  A /-vtLOAOX/W[4:7hW[4:7]:  (5  8) 

***»*REWRirE  230  BY  { M6); 

231  /-tLOADX/W[0:3]&W[4:7>W[0:3]&W[4:7];  (5  8) 

*»***REWRITE  231  BY  CONCATENATE; 

232  /-tLOADX/V[0;7]-W[0:7];  (5  8) 

♦****SUBSTR  60  IN  232; 

233  /•vt^(LOADuCLOCK)/W[0:7>W[0:7];  (15  8) 

•••••REWRITE  233  BY  { T14A): 


234  /~f(~LOAOn~CLOCK)/W[e;7>W[0:7];  (1  5 8) 
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*****REWRITE  234  BY  TRANS; 

235  /-( ( *LOADn-CLOCIC)u(~LOAOn*CLOCK))/W[0:7>W[0:7];  (15  8) 
**»**REWRITE  44  BY  REDUCE; 

236  /LOAOn^tCLOCK/Of0:3]-O[»:3];  (44) 

*****REWRITE  50  BY  REDUCE; 

237  /LOADn-tG/DONE-DONE;  (50) 

*****SUBSTR  111  IN  237; 

238  /LOADn-vt~(Q[0:3]«15)/DONE-DONE;  (45  46  50) 

*****REWRITE  238  BY  TRANS; 

239  /LOADn-v*(Q[0:3]«15)/DONE-DONE;  (45  46  50) 

***»*aI  (24  29) ; 

240  /LOADn.viCLK/Z[0:3>Z[0:3];  A /LOADn~*CLIC/Z[4:7>Z[4:7];  (24  29) 

*****REWRITE  240  BY  { M6); 

241  /LOADn-viCLK/Z[0:3]&Z[4:7>Z[0:3]&Zt4:7]j  (24  29) 

*****REWRITE  241  BY  CONCATENATE; 

242  /LOADn~*CLK/Z[0:7]-Z[0:7];  (24  29) 

*****aI  (34  39 ) ; 

243  /ln-*CL</Z[8;ll>Z[8:ll];  A /lrw*CLK/Z[  12: 15>Z[  12: 15];  (34  39) 

*****REWRITE  243  BY  { MB); 

244  /ln>-iCLIC/Z[8:ll]&Z[12:15>Z[8:ll]«.Z[12:15];  (34  39) 

*****REWRITE  244  BY  CONCATENATE; 

245  /ln~*CLK/Z[8;15]-Z[8:15];-  (34  39) 

*****REWRITE  245  BY  REDUCE; 

246  /-*CLK/Z[8;15>Z[8;15];  (34  39) 

»****VE  M10  -*CLK,LOAD,Z[8:15],Z[8:15]; 

247  /-iClK/Z[8:15>Z[8:15];  = /~*CLKnL0AD/Z[8: 15>Z[8: 15]; 

*****TAUT  /~*CLKnLOAD/Z[8:15]«-Z[8:15];  246:247; 

248  /~*CLKnLOAD/Z[8:15]*-Z[8:15];  (34  39) 

*****VE  T7B  ~*CLK.LOAD; 

249  (-viCLKnLOAD)  = (LOADn~iCLK) 
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•****SUBSTR  249  IN  248; 

250  /LOADrvv*CLK/Z[8:15>-Z[0:15];  (34  39) 

*****/Nl  (242  250); 

251  /LOAOn-iCLK/Z[0:7]-Z[O:7);  A /LOAOfw*CLK/Z[8:l5]-Z[8:l5];  (24  2X 

9 34  39) 

**in**REWRITE  251  BY  ( M6); 

252  /LOADn~*CLIC/Z[0:7]&Z[8:15>-Z[e:7]&Z[8:15];  (24  29  34  39) 

**»**REWRITE  252  BY  CONCATENATE; 

253  /LOAOn-v*CLIC/Z[O:15>Z[0:15];  (24  29  34  39) 

*****REWRITE  19  BY  REDUCE; 

254  /LOADn^tC/OV-OV;  (19) 

*****SUBSTR  144  IN  254; 

255  /LOADn-t^CLK/OV-OV;  (15  19) 

*****REWRITE  255  BY  TRANS; 

256  /LOADn-*CLK/OV-OV;  (15  19) 

*****aI  (256  253); 

257  /LOADn-iCLIC/OV-OV;  a /LOADn^*CLK/2[$:  15]-Z[0:  15];  . (15  19  24  29  X 
34  39) 

*****REWRITE  257  BY  { M6); 

258  /LOADn~tCLK/OV&Z[4:15]-OV&Z[0:l5];  (15  19  24  29  34  39) 

*****SUBSTR  93  IN  258; 

259  /LOADn~*(CLOCKuDONE)/OV8.Z[0:15>OV&Z[8:15];  (15  19  24  29  34  39  X 

51) 

»****REWRITE  259  BY  TRANS; 

260  /LOADn-((iCLOCKn~DONE)u(~CLOCKn*DONE))/OV«t0:15>OV&Z[8:15];  (X 
15  19  24  29  34  39  51) 
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13.  CONCLUSIONS 


This  thosis  has  demonstrated  how  theorem  proving  can  be  applied  to  showing 
tlie  correctness  of  digital  circuit  designs.  Using  the  FOL  proof  checker  may,  at 
first  glance,  appear  to  be  an  awkward  and  expensive  process  in  terms  of 
computer  use.  This  is  especially  true  tor  simple  circuits.  The  correctness  of  the 
4-bit  binary  counters  could  have  been  determined  by  any  digital  simulator  in 
about  1 6 cycles. 

On  the  other  hand,  the  theorem  proving  approach  becomes  much  more 
attractive  when  verifying  complex  circuits  made  up  of  MSI  and  LSI  components. 

To  exhaustively  simulate  the  8-bit  multiplier  would  have  required  2^®  (66,636) 
multiplications  at  one  load  cycle  and  16  clock  cycles  each.  If  we  wanted  to 
verify  a 16-bit  multiplier  of  similar  design  using  simulation  It  would  take  2®^ 
(4,294,967,296)  multiplications  with  one  load  cycle  and  32  clock  cycles  each. 
Proving  the  correctness  of  a 16-blt  multiplier  using  FOL  might  require  twice  as 
many  steps  as  for  the  8-bit  unit,  and  possibly  far  less  if  certain  quantifiers  are 
properly  manipulated. 

After  working  with  the  FOL  verifier  for  a short  period  It  becomes  surprisingly 
easy  to  use.  There  are  a many  features  that  could  be  added  to  the  current 
system  to  make  proofs  of  correctness  for  hardware  much  more  concise. 
Automatic  boolean  minimization  would  help.  Even  better  would  be  a subroutine 
similar  the  FOL  tautology  mechanism  that  can  compare  two  boolean  expressions 
and  determine  if  they  are  equivalent  or  if  one  Implies  the  other, 
f 

i A considerable  amount  of  work  will  have  to  be  done  to  get  the  races  and 

I hazards  information  into  the  proof  checker.  It  may  be  reasonable  to  develop 

i some  axioms  that  indicate  under  what  conditions  a circuit  will  be  free  of  these 

problems.  Another  approach  would  be  to  Include  statistical  information  on 
f component  delays  In  the  circuit  description  and  attempt  to  determine  the 

\ probability  of  a race  or  hazard.  Some  additional  study  of  the  properties  of  non- 

f transitions  is  also  needed. 

I Other  improvements  in  hardware  verification  hinge  on  the  adaptation  of 

t program  verification  techniques.  It  would  be  nice  to  be  able  to  make  assertions 

about  what  a device  will  do  as  a result  of  a sequence  of  Input  transitions.  On  an 
! algorithmic  level  it  is  much  easier  to  define  processes  using  a procedural  register 

I transfer  language.  Therefore,  it  would  be  advantageous  to  develop  a verifier 

i based  on  a procedural  register  transfer  language.  Finally,  there  is  the  need  to 

* j interface  the  language  presented  here  with  a microprogram  verification  system. 

E This  would  make  It  possible  for  the  user  to  prove  the  correctness  of  a 

( ' microprogram  in  conjunction  with  a specific  digital  device. 
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Appendix  A.  BNF  LANGUAGE  DESCRIPTION 


< letter > 

A|B|C|...|ZrL 

<d1git> 

; ;=  e|l|2|3|4|5|6|7|8|9 

<transition> 

::=  t|* 

<unary_oper> 


<binary_oper> 

: ;=  a|v|«|+| - 

I <ar i th_re1at ion> 

::=  S|^l<|>|^|= 

<1dentitier> 

: :=  <1etter> 

::=  <ident1f1er><1etter> 

::=  < identif  lerXdiglt) 

<Constant> 

; :=  <digit> 

;:=  <constant><d1g1t> 

<stateinent> 

<var>«-<exp>; 

::=  /<cond_exp>/<var>«-<exp>; 

<cond_exp> 

: :=  <identif1er> 

; :=  <identif1er>[<exp>] 

::=  <1dent1f 1er>[<exp>,<exp>] 

::=  <transition><cond_exp> 

<unary_oper><cond~oxp> 

: :=  <cond_ixp><b<nary”op8r><cond^«xp> 

<exp><arlth_relatTon><exp> 

<exp> 

: :=  <constant> 

: ;=  <var> 

::=  <unary_oper><exp> 

' ::=  <exp><b1nary_oper><exp> 

; ::=  <exp><arith_relat1on><exp> 

! ::=  <exp>&<exp> 

i : :=  (<exp>) 

::=  (<cond_exp>) 

BEST  AVAIUBIE  COPY 
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<var  > 

::=  <identifier> 

::s  <1dentif 1er>[<exp>] 

::=  < identifier >[<exp>,<exp>] 

: :=  <ident1f 1er>[<constant>;<constant>] 

: :=  <1dent1f1er>[<constant>:<constant>,<exp>] 
::=  <var>8i<var> 

:;=  <ident1f 1er>[*<exp>] 

::=  < Identif 1er>[*<exp>,<exp>] 

<1dent1f 1er>[<exp>,*<exp>] 

: :=  < Identif 1er>[<constant>:<constant>,a<exp>] 


Appendix  B.  LIST  OF  TRANSFORMATIONS 


11.  -.0  = 1 

-.1=0 

Tc’.  Xvl  = 1 
XaO  = 0 

13.  XvO  5 X 
XaI  s X 

I'l.  XvX  E X 
XaX  e X 

15.  -.(-.X)  E X 

16.  Xv.,X  s 1 
Xa-,X  s 0 

1 / . XvY  E YvX 
XaY  e YaX 

10.  Xv(XaY)  e X 
Xa(XvY)  e X 

111.  (Xv-,Y)aY  s XaY 
(Xa-,Y)vY  s XvY 

lie.  (XvY/vz  s xv(yvz) 

(XaY)aZ  s Xa(YaZ) 

in.  Xa(YvZ)  s (XaY)v(XaZ) 

Xv(YaZ)  s (XvY)a(XvZ) 

112.  (XvY)a(^XvZ)a(YvZ)  s ( XvY)a(-.XvZ ) 
(XaY)v(-,XaZ)v(YaZ)  s (XaY)v(-,XaZ) 

11.3.  (XvY)a(-.XvZ)  s (XaZ)v(-,XaY) 


114.  -.(XvY)  s -,Xa-.Y 
n(XAY)  s -Xv-iY 

Xl  . (Xa-.Y)v(-,XaY)  • X«Y 

X2.  X»0  s X 

X3.  X»1  s -,X 

X4.  X»X  s 0 

X5.  X*-.X  e 1 

X6.  X*Y  s Y*X 

X7.  (X«y)«Z  s X«(Y*Z) 

X8.  -.(X»Y)  s -.X«Y 


Appendix  B 


B1 


Dl.  A[i]  ■ A[i;1] 

02.  A[1:J]  I A[1:J.0] 

03.  A[1:J.s]&A[j4l:k.s]  ■ A[1:k,s] 
where  1^J<k 

04.  iA[1:j,s]&-.A[j4l:k,s]  ■ -ACIrk.s] 
where  iij<k 

05.  (X&Y)&Z  ■ X&(Y&Z) 

06.  (X[i:J]AY[1:J])&(X[J+l:k]AY[J+l:k])  ■ Xt 1 :k]AY[ 1 ;k] 
where  1^J<k 

07.  (X[1:J]vY[1:J])&(X[J*l:k3vY[J+lsk])  i X[i:k]vY[l!k] 
where  1^J<k 

08.  (X[1:J]eY[1:j])MX[J+l:k]eY[J+l:k])  ■ X[1:k>Y[1;k] 
where  1^j<k 

09.  m A[Y[1:j],s]-Z; 

■ 

/XA(Y[1:J]=n)/  A[n,s]«-Z; 

010.  /X/  A[s,Y[1:j]>Z; 

i 

/XA(Y[1:j]=n)/  A[s,n>-Z; 

011.  A[Y[i:J].s]  i 

(A[0,s]a(Y[1:J>0))v(A[1,s]a(Y[1:JM))v,..v 

(A[n,s]A(Yt1:J]=n)) 

when  A[Y[1:j],s]  Is  used  In  an  expression 

012.  A[s,Y[1:J]]  1 

(A[s,0]A(Y[1:j]=0))v(A[s,l]A(Y[1:j]*l))v...v 

(A[s,n]A(Y[i:j]=n)) 

when  A[s,Y[1:J]]  Is  used  In  an  expression 


Al.  X[1]aY[1]v(X[1]vY[1])aCI  I carry(X[ 1 ]. Y[ 1 ],CI) 

X[1]AY[1]v(X[1]vY[1])Acarry(X[l4l:J],Ytl4l:J],CI)  a 
carry(X[i:J].Y[1:J],CI) 

A2.  carry(X[i:J].Y[1.J],carry(X[j4l:k],Y[j4l,k],CI)  e 
carry(X[1:k].Y[1:k],CI) 
where  1$J<k 

A3 . ( X[ 1 ]eY[ 1 ]*CARRY( X[ 1*1 : J ] , Y[ 1+ 1 : J ],  Cl  )& 

(X[1+l]eYri4l>CARRY(X[l42:J],Y[l42:J],CI)«i...0i 
(X[J>Y[J]#CI)  ■ Xt1:J>Y[1:J]4CI 

A4.  (X[1:J]4Y[1;J]+CARRY(X[j4l,k],Y[j4i,k],CI))4 

(X[j4l:k>Y[j4l:k]+CI)  a X[1:kl4Y[l!k]4CI 
where  1$J<k 


BESI  AVAILABLE  COPY 
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A5.  X(  1 :j  )+-.¥[  i :j]+l  s X[  i : J]-Y[  i : j]  (for  2’s  complement) 
xi  i : j J+->Yl  t:  j]+0  5 X[  i : j]-Y[  i : j]  (for  I’s  complement) 

A6.  XI  1 ]«(X1  i+ljA...AX[j])&X[i  + l]*(X[i+2]A..,AX[J])«....8t-.X[J] 
s XI  i.jj+l 

A7.  -.X[  i>Yl  i]  = X[i]=Y[i] 

A8.  (Xli>Ytn)A(X[i  + l]=Y[1  + l])A...A(X[j]=Y[J])  ■ X[1;J]«Y[1:J] 

A9.  (X(  i:j]=Yli;j])A(X[j+l:k]=Y[J+l:k])  ■ X[ 1 :k]»Y[ 1 :k] 

where  iij<k 

AlO.  -,(X(  1:j]=Y[  i:j])  s X[  i : j]^Y[  1 : j] 

All.  X[  i]A-.Y[i]  5 X[1]>Y[1] 

Al,'’.  (X[  i]>Y[  1])v((X[i]=Y[i])AX[i4l]>Y[i  + l])v.,.v 

((X[  i:j-l]=Y[i:j-l])AX[J]>Y[j])  i X[  i : j]>Y[  1 : j] 

A13.  (X[  i:j]>Y[  i:j])v((X[i:j]=Y[i:j])AX[j4l:k]>Y[j4l:k]) 

= X[  i :k]>Y[  i .-k] 
where  iij<k 

A14.  Y[  1 :j]>X[  i :J]  s X[  i : j ]<  Y[  i : j ] 

A15.  -(XI  i:j]>Y[1:j])  i X[  i : j]iY[  i : j] 

A16.  -(Yli:j]>X[i:J])  i X[  1 : J]2Y[  i : j] 


Ml . A-Y;  = /!/  A^Y; 

M2.  /!/  A-Y;  3 (A  i Y) 

M3.  /Wa-X/  A«-Y; 

/Wa  X/  A-Z; 

/W/  A-(-.XaY)v(XaZ); 

m.  /X/  A-,..Y...; 

/Xa  Y/  A»-...1...; 

/Xa-Y/  A-...0...; 

M5.  /XvY/  A-Z; 

/X/  A-Z; 

/Y/  A-Z; 

M6.  /X/  A-Y;  (note:  A and  Y must  be  the  seme 

/X/  B-Z;  length,  same  for  B and  Z) 

£ 

/X/  A&B-Y&Z; 


! 


] 

\ 


1 
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M7.  m 

and  (XsY) 

a 

/X/ 

M8.  m A^..^Y...; 

and  (XaY) 

a 

/X/  A-...0...; 

M9.  /X/  A-...B...; 

/Y/  B«-2; 
and  (XaY) 

D 

/X/  A-...2...; 
M10.  /X/  A-Z; 

/XaY/  A«-Z; 

Mil.  /X/  A-Y; 

3 

XaA  a XaY; 

Xa-iA  a XaiY; 


FI.  /X/  A[*Y[1:J],s]-Z; 

a 

/XA(Yti:J]iin)/  Atn,s>2; 

F2.  /X/  A[s,#r[1:J]>Z; 

a 

/XA(y[1:j]an)/  A[5,n>-Z; 

.F3.  /X/  A[*Yt1;J],s>A[*Y[i:J],s]; 

a 

/XA(Y[1:J]i«n)/  A[n,*>A[n,s]; 
F4.  /X/  A[s,*Y[1:J]>-Ata,*Y[1:J]]; 

/XA(Y[l:J>n)/  Ars,n>-Al8,n]; 


Cl . ta  a 0 
tl  a 0 
«e  a 0 
41  a 0 

CZ.  tXAiX  a 0 

C3.  tXAtY  a 0 
tXA4Y  a 0 
4XAtY  a 0 
4Xa4Y  a 0 


Apptndix  B 


tX«tY  5 tXvtY 
tX«*Y  E fXvtY 
4X«tY  E *XvtY 
iX»iY  s *Xv4Y 

tfX  E fX 
t*X  E tX 
ItX  E tX 
iiX  s IX 

CO.  t-,X  s IX 
I-.X  s tX 

t(XAY)  E ( tXAY)v(XAtY) 
i(XaY)  e ( iXaY)v(XaIY) 

f(XvY)  s ( tXA-.Y)v(-,XAtY) 
i(XvY)  s (iXa-.Y)v(-,Xa*Y) 

9.  /X/  A-Y; 

o 

1A  E (XAfY)v(-.AAYAfX) 

♦ A E (XAiY)v(AA-.YAtX) 
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Appendix  C.  TRANSITIONS  THRU  HAZARDS 


STATIC  1 HAZARD 
1.  t(XAY  V iXaZ)  « 

t(XAY)A-.(-,XAZ)  V t(nXAZ)Ai()(AY)  « 

(tXAY  V XAtY)A(X  V -Z)  V (*XaZ  v ^XAtZ)A(iX  V -^Y)  » 

( tXAYAX)v(  tXAYA-.Z)v(XAtYMXAtYA-.Z)v 
( *XaZa-.X  )v(  ^XaZaiY  )y(  iXAtZ  )v(  -^Xa tZA-iY ) « 

( tXAXAY)v(  tXAYA-.Z)v(XAtY)v(  *Xa-.XaZM  *XA-iYAZ)v(-,XAtZ) 


STATIC  1 HAZARD  WITH  CONSENSUS  GATE  ADDED 

2.  t(XAY  V -XaZ  V YaZ)  = 

t(XAY)A-.(-.XAZ)A^(YAZ)  V 
t(-.XAZ)A-.(XAY)An(YAZ)  V 
t(YAZ)A-.(XAY)A-.(-.XAZ)  » 

t(XAY)A(X  V -,Z)a(-.Y  V iZ)  V 
t(-.XAZ)A(-.X  V -.Y)a(-.Y  V tZ)  V 
t(YAZ)A(-.X  V •,Y)a(X  V -.Z)  ■ 

(tXAY  V XAtY)A(XA-.Y  V nZ)  V 
(tXAZ  V -.XAtZ)A(-.XA-.Z  V -.Y)  V 
(tYAZ  V YAtZ)A(-.XA-.Z  V Xa-Y)  = 

( t XaYaiZ  )v(  XAt YA-.Y  )v(  XAtYA-.Z  )v 
( *Xa-.YaZ  M --Xa  tZA-^Z  M-»XA-iYAtZ  )v 
(XAtYA-.YAZ)v(-,XAYAtZA-.Z)  « 

( t XaYaiZ  )v(  Xa  t Ya-,Y  )v(  XAt  YaiZ  )v(  *Xa-.YaZ  )v( -•XAtZA-.Z  )v( -iXA-iYAt  z ) 


STATIC  $ HAZARD 

3.  t((X  V Y)a(-,X  V Z))  » 

t(X  V Y)a(-.X  V Z)  V t(^X  V Z)a(X  V Y)  « 

(tXA-.Y  V -.XAtY)A(-.X  V Z)  V («Xa-.Z  v XAtZ)A(X  V Y)  « 

( tXA-.YA-.XM  tXA-.YAZ)v(-.XAtY)v(-.XAtYAZ)v 
( *Xa-.ZaX)v( ♦XA-.ZAY)v(XAtZ)v(XAtZAY)  « 

( t XV-.XA-.Y )v(  tXA-.YAZ  )v(  -.XAt Y)v(  *XaXa-.Z  )v(  «XaYa-.Z  )v(  XAtZ ) 


BtSi  AVAIUBit  COPY 
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STATIC  0 HAZARD  WITH  CONSENSUS  GATE  ADDED 

4.  ♦((X  V Y)a(-.X  V Z)a(Y  V Z))  = 

t(X  V Y)a(^X  V Z)a(Y  V Z)  V 
t(-,X  V Z)A(X  V Y)a(Y  V Z)  V 
t(Y  V Z)A(X  V Y)a(^X  V Z)  = 

(tXA-.Y  V -.XAtY)A(-iXAY  V Z)  V 
(JXa-,Z  V XAtZ)A(XAZ  V Y)  V 
(tYA-,Z  V -,YAtZ)A(XAZ  V -.XaY)  = 

( tXA-,YAZ)v(-.XAtYAY)v(-.XAtYAZ)v 
(iXAYAZ)v(XAtZAZ)v(XAYATZ)V 
( -»Xa  t Ya YatZ  )v(  Xa^Ya t ZaZ  ) - 

( tXA-.YAZ)v(-.XAtYAY)v(-.XAtYAZ)v(*XAYAZ)v(XAtZAZ)v(XAYAtZ) 


f 

r 


i: 
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Appendix  0.  FOL  DECLARATIONS  AND  AXIOMS 


DECLARE  PREDCONST  BOOL  1; 

DECLARE  PREDCONST  F (BOOL, BOOL, BOOL ) ; 

DECLARE  INDVAR  a ,b,c,d,e, f ,g,h, 1 , J,k, 1 ,m,n,o,p,q.r, s, t,u, v,w,x,y,z; 
DECLARE  OPCONST  ~(BOOL)=BOOL  [R-850]: 

DECLARE  OPCONST  t(BOOL)=BOOL  tR*-750]; 

DECLARE  OPCONST  *(BOOL)=BOOL  [R»-750]; 

DECLARE  OPCONST  «t(BOOL,BOOL)»BOOL  [ L*-600 , R«-650 ] ; 

DECLARE  OPCONST  ♦ (BOOL, BOOL )« BOOL  [L«-500,R*-550]; 

DECLARE  OPCONST  - (BOOL,  BOOL  )= BOOL  [L*-500,R*-550]; 

DECLARE  OPCONST  « (BOOL, BOOL )= BOOL  [L*-400,R*-450]; 

DECLARE  OPCONST  # (BOOL, BOOL )= BOOL  [L*-400,R*-450]; 

DECLARE  OPCONST  > (BOOL, BOOL )= BOOL  [L*-400,R«-450]; 

DECLARE  OPCONST  <( BOOL, BOOL )=BOOL  [L«-400,R-450]; 

DECLARE  OPCONST  2:(B00L,B00L)=B00L  [L‘-400,R*-450]; 

DECLARE  OPCONST  S( BOOL, BOOL )= BOOL  [L*-400,R*-450]; 

DECLARE  OPCONST  n( BOOL, BOOL )= BOOL  [L«-300,R-350]; 

DECLARE  OPCONST  u( BOOL, BOOL )=BOOL  [L‘-200,R*-250]; 

DECLARE  OPCONST  • (BOOL, BOOL )= BOOL  [L*-200,R-258]; 

DECLARE  OPCONST  carry (BOOL, BOOL, BOOL )= BOOL; 

DECLARE  OPCONST  sub(BOOL,NATNUM,NATNUH)»BOOL; 

DECLARE  OPCONST  suc(NATNUM)=NATNUI1; 

REPRESENT  {NATNUM}  AS  NATNUMREP; 

ATTACH  sue  TO  (LAMBDA  (X)(ADD1  X)); 


AXIOM  TIA: 
AXIOM  TIB: 
AXIOM  T2A: 
AXIOM  T2B: 
AXIOM  T3A: 
AXIOM  T3B: 
AXIOM  T4A: 
AXIOM 
AXIOM 
AXIOM 
AXIOM 


~0=1 ; ; 
'>'1=0 ; ; 
VX.  XUl: 


T4B: 

T5: 

T6A: 

T6B: 


Vx. 

Vx. 

Vx. 

Vx. 

Vx. 

Vx. 

Vx. 

Vx 


1 


xn0=0 
xu0=x 
xnl=x 
xux=x; ; 
xnx=x ; ; 
~(-x)=x;,; 
xu^x=l  Vx 
xn^x=0  Vx 


Vx.  luxsl; 
Vx.  0nxe0; 
Vx.  0UXSX; 
Vx.  Inxex; 


"Xuxsl; ; 
'vxnx=0: ; 


REDUCE-LOGlCtREE  u{TlA,TlB,T2A,T2B,T3A,T3B,T4A,T4B,T5,T6A,T6B); 


AXIOM  T7B:  Vx  y.  xnysynx;; 

AXIOM  T10B:  Vx  y z.  (xny)nz=xn(ynz); ; 

AXIOM  T10BR:  Vx  y z.  xn(ynz)=(xny)nz; ; 

AXIOM  TllA:  Vx  y z.  xn(yuz)=(xny)u(xnz) ; ; 

AXIOM  T14A:  Vx  y.  'v(xuy)='vXfKy; ; 

AXIOM  T14B:  Vx  y.  *'(xny)»<vXiKy; ; 

AXIOM  XI:  Vx  y.  xn^yuvxny=xey; ; 

AXIOM  X6:  Vx  y.  xeysyex;; 

AXIOM  D3:  Vx  1 J k.  sub(x,1,J)&sub(x,suc(J),k)>sub(x,1,k); ; 

AXIOM  D5:  Vx  y z.  (x&y)&z=x&(y&z) ; ; 

AXIOM  A2:  Vx  y c 1 j k. 

carry(sub(x,1,J),sub(y,1,  j),carry(sub(x,suc(J),k),sub(y,suc(J),k),c))« 
carry(sub(x,1,k),sub(y,1,k),c);; 

AXIOM  A4:  Vx  y c i j k. 

(sub(x,1,J)*sub(y,1,J)+carry(sub(x,suc(J),k),sub(y,suc(J),k),c))ai 

(sub(x,suc(J),k)*sub(y,suc(J),k)+c)=(sub(x,1,k)*sub(y,1,k)+c);; 

AXIOM  A6:  Vw  x y z.  (*fe(xnynz))4(xe(ynz))ai(yez)&(«»z)«w&x&y&z+I; ; 


BI:S]  AV/JlAblt  LUP 
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AXIOM  M2:  Vx  y.  (F(  1 ,x,y )3(x«y) ) ; ; 

AXIOM  M3:  Vw  x a y z.  (F(wnx,a,y)AF(wfKX,a,z)iF(w,a,xnyiKxnz) ) ;j 

AXIOM  M5:  Vx  y a z.  (F(xuy,a,z)iF(x,a,z)AF(y,a,z)); ; 

AXIOM  M6:  Vx  a y b z.  (F(x,a,y)AF(x,b,z)aF(x,aatb,y4z)); ; 

AXIOM  M7:  Vx  a y z.  (F(xny,a,ynz)iF(xny,B,z)); ; 

AXIOM  M8:  Vx  a y z.  (F(xny,a,~ynz)iF(xny,a,e)); ; 

AXIOM  MIO:  Vx  y a z.  (F(x,a,z)3F(xny,a,z)); ; 

AXIOM  MllA:  Vx  a y.  (F(x,a,y)3(xna=xny) ) ; ; 

AXIOM  MllB:  Vx  a y.  (F(x,a,y)3(x(Vva)=(xfwy)); ; 

AXIOM  CIA:  f0=0: ; 

AXIOM  CIB:  tl=0;; 

AXIOM  CIC:  i0=0:; 

AXIOM  CIO:  *1=0;; 

AXIOM  C3A:  Vx  y.  txnty=0;; 

AXIOM  C3B:  Vx  y.  txn*y=0;; 

AXIOM  C3C:  Vx  y.  *xnty=0;; 

AXIOM  C3D:  Vx  y.  *xn*y=0;; 

AXIOM  C5A:  Vx.  ttx=tx; ; 

AXIOM  C5B;  Vx . tix=*x;; 

AXIOM  C5C:  Vx.  *tx=tx;; 

AXIOM  C5D:  Vx.  **x=*x;; 

AXIOM  C6A:  Vx.  t~x=*x;; 

AXIOM  C6B:  Vx.  *-x=tx;; 

AXIOM  C7A:  Vx  y.  t(xny)=(  txny)u(xnty); ; 

AXIOM  C7B:  Vx  y.  *(xny)=( *xny)u(xn*y) ; ; 

AXIOM  C8A:  Vx  y.  t(xuy)=(  rxn^y)u(<-xnty) ; ; 

AXIOM  C8B:  Vx  y.  *(xuy)=( *xn~y)u(vxn*y) ; ; 

IRANS-LOGICTREE  U{C1A,C1B,C1C,C1D,C3A,C3B,C3C,C3D,C5A,C5B,C5C,C5D, 

C6A,C6B,C7A,C7B,C8A.C8B}; 

AXIOM  C9A:  Vx  a y.  (F(x,a,y)3(ta=(xnty)u(~anyntx)));; 

AXIOM  C9B:  Vx  a y.  (F(x,a,y)3( *a=(xn*y)u(an~yntx))); ; 

AXIOM  CON:  Vx  i j.  ( sub(x,  1 ,0 )aisub(x,  1 , j )=sub(x,  1 , J) ) 

Vx  1 J.  (sub(x,i,l)&sub(x,2,3)=sub(x,1,J)) 

Vx  1 j.  (sub(x,1,2)&sub(x,3,j)=sub(x,1 J)) 

Vx  i j.  (sub(x, 1,3)&sub(x,4,J)»sub(x,1,j)) 

Vx  1 j.  (sub(x,1,4)&sub(x,5,J)=sub(x,1,J)) 

Vx  i J.  (sub(x,1,5)8isub(x,6,J)=sub(x,1J)) 

Vx  1 j.  (sub(x,1,6)&sub(x,7,J)=sub(x,1,J)) 

Vx  1 j.  (sub(x,1,7)&sub(x,8,J)=sub(x,1,J)) 

Vx  i j.  (sub(x,i,8)&sub(x,9,J)=sub(x,1,J)) 

Vx  1 J.  (sub(x,1.9)aisub(x,10,J)=sub(x,1,J)) 

Vx  1 J.  (sub(x,1,ie)&sub(x.ll j)=sub(x,1,j)) 

Vx  1 j.  (sub(x,1,ll)&sub(x,12 J)=sub(x,1,3)) 

Vx  1 J.  (sub(x,i,12)8isub(x,13,j)=sub(x,1,J)) 

Vx  1 j.  (sub(x,1,13)&sub(x,14,3)=sub(x,1,J)) 

Vx  1 j.  (sub(x,i,14)&sub(x,15 ,3)>sub(x,1,J));; 
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Appendix  E.  COMPONENT  DEFINITIONS 


Combinational  devices 


0--.(XvY);  (7402) 
0--.X;  (7404) 
0-XaY;  (7408) 
(>-XaYaZ;  (7411) 
Q-XvY;  (7432) 

Type  D flip-flop  (7474) 


/-.S/  Q«-l; 

/Sa-iR/  Q*-8; 

/SARAtC/  0<-D; 

/SARAitC/  Q^Q; 

/-R/  Q’-l; 

/R/  Q’^-O; 

Edge  triggered  JK  (74103) 

/-.R/  Q«-0; 

/Ra*C/  Q**( OaiO)v( tKaQ) ; . 

/Ra-i*C/  Q«-Q; 

4-b1t  binary  counter  (74161) 

/-.RESET/  Q[0;3>0; 

/RESETAnlOADAtCOUNT/  O[»:3>DATA[0;3]; 
/RESETA-.LOADA-.tCOUNT/  Q[0;3>Q[0;3]; 
/RESETaLOADaENBPaENB  TAt  COUNT/  Q[  0 : 3 ]♦<)[  0 : 3 ]+ 1 ; 
/RESETALOADA-.(ENBPAENBTAtCOUNT)/  Q[0:3>Q[0:3]: 
CRY*-(O[0:3]=15); 

Quad  type-D  flip-flop  (74175) 

/-RESET/  O[0:3]-0; 

/RESETAtC/  O[0:3>-O[0:3]; 

/RESETA-tC/  O[0:3]-O[0:3]; 

4-b1t  shift  register  (74179) 

/-CLEAR/  Q[0:3>0; 

/C  LE ARa  * CLOCKaSHIF  T/  0[  0 : 3 >SERIAL&Q[  0:2]; 
/CLEARaICLOCKa-SHIFTaLOAO/  Q[0:3>DATA[0:3]; 
/CLEARa*CLOCKa-.SHIFTa-LOAD/  Q[0:3>Q[0:3]: 
/CLEARa-*CLOCK/  O[0:3>Ot0:3]; 

4-b1t  binary  adder  (74283) 

SUM[0:3>At0:3]*B[0:3]*CI; 

CO.-CARRY(At0:3],Bt0:3],CI); 


